View a markdown version of this page

GitLab Token de acceso - AWS Secrets Manager

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

GitLab Token de acceso

Campos de valor secreto

Los siguientes son los campos que deben estar incluidos en el secreto de Secrets Manager:

{ "token": "GitLab access token value", "tokenId": "numeric token ID", "gitlabUrl": "GitLab instance URL", "projectId": "project ID (optional)", "groupId": "group ID (optional)" }
token

El valor del token de GitLab acceso (comienza porglpat-). Este es el campo que se rota.

ID del token

El ID numérico del token. Se actualizó cada rotación con el identificador del nuevo token.

URL de GitLab

La URL de tu GitLab instancia (por ejemplo,https://gitlab.com). Debe usar HTTPS.

projectId

(Opcional) ID numérico del proyecto. Proporcione únicamente los tokens de acceso al proyecto.

groupId

(Opcional) ID de grupo numérico. Proporcione únicamente los tokens de acceso grupal.

Campos de metadatos secretos

Los siguientes son los campos de metadatos del token de GitLab acceso:

{ "adminSecretArn": "arn:aws:secretsmanager:us-east-1:111122223333:secret:GitLabAdmin", "daysToExpiry": "30 (optional)" }
administrador SecretArn

(Opcional) El nombre de recurso de Amazon (ARN) de un tipo de secreto GitLabAccessToken que contiene un token de GitLab acceso con alcance de API que se utiliza para rotar este secreto. Si se omite, el token se rota solo (obligatorio o limitado). api self_rotate En el caso de los tokens del proyecto, el token de administrador debe tener la función de mantenedor en el proyecto. En el caso de los tokens de grupo, se necesita el rol de propietario en el grupo.

días ToExpiry

(Opcional) Número de días que faltan para que caduque el nuevo token (de 1 a 365). Se asigna al expires_at campo de la API de GitLab rotación. Si se omite, el nuevo token hereda la caducidad predeterminada de la instancia.

Flujo de uso

Esta rotación admite arquitecturas de un solo secreto (autorrotación) y de dos secretos (asistida por el administrador). El alcance del token viene determinado por los campos opcional y. projectId groupId Si ninguno de los campos está presente, el token es un token de acceso personal. Si projectId está presente, el token es un token de acceso al proyecto. Si groupId está presente, el token es un token de acceso grupal.

Crea tu secreto mediante la CreateSecretllamada. Establezca el valor secreto en los campos descritos anteriormente y establezca el tipo de secreto en GitLabAccessToken. Para configurar la rotación, utilice la RotateSecretllamada. Proporcione un ARN de rol que otorgue al servicio los permisos necesarios para rotar el secreto. Para ver un ejemplo de una política de permisos, consulte Seguridad y permisos.

Cuando se utiliza la rotación asistida por un administrador, el secreto de administrador también es de tipo. GitLabAccessToken Debe proporcionar explícitamente al rol de rotación el acceso al secreto de administrador. Para ello, agrega una declaración relacionada con el ARN secreto del administrador directamente en la política de roles.

Durante la rotación, el conductor valida que el token actual esté activo. A continuación, llama al punto final de GitLab rotación, que crea atómicamente un nuevo token y revoca el anterior. Secrets Manager almacena el nuevo valor e ID del token como AWSPENDING, los verifica mediante la GitLab API y los promociona a AWSCURRENT. Las aplicaciones que utilizan la biblioteca de almacenamiento en caché Secrets Manager recogerán automáticamente el nuevo token en su próxima actualización.