doc-locale/fr-fr/ci/cloud_services/aws/_index.md
{{< details >}}
{{< /details >}}
[!warning]
CI_JOB_JWT_V2a été déprécié dans GitLab 15.9 et est prévu d'être supprimé dans GitLab 17.0. Utilisez plutôt les jetons d'ID.
Ce tutoriel vous explique comment utiliser un job GitLab CI/CD avec un JSON web token (JWT) pour récupérer des informations d'identification temporaires depuis AWS sans stocker de secrets. Pour ce faire, vous devez configurer OpenID Connect (OIDC) pour la fédération d'identités entre GitLab et AWS. Pour les informations générales et les prérequis pour l'intégration de GitLab avec OIDC, consultez Se connecter aux services cloud.
Pour suivre ce tutoriel :
Créez GitLab en tant que fournisseur OIDC IAM dans AWS en suivant ces instructions.
Incluez les informations suivantes :
URL du fournisseur : L'adresse de votre instance GitLab, par exemple https://gitlab.com ou http://gitlab.example.com. Cette adresse doit être accessible publiquement. Si elle n'est pas accessible publiquement, consultez la procédure pour configurer une instance GitLab non publique
Audience : Le nom logique du service cible avec lequel vous souhaitez utiliser le jeton de sécurité demandé.
sts.amazonaws.com ou l'URL de votre instance GitLab).[!note] L'utilisation de
https://gitlab.comou de l'URL de votre instance GitLab peut fonctionner si la référence du fournisseur d'identité AWS correspond, mais cela est sémantiquement trompeur. L'audience doit représenter le service qui valide et accepte le jeton.
Après avoir créé le fournisseur d'identité, configurez un rôle d'identité web avec des conditions pour limiter l'accès aux ressources GitLab. Les informations d'identification temporaires sont obtenues à l'aide d'AWS Security Token Service. Définissez donc Action sur sts:AssumeRoleWithWebIdentity.
Vous pouvez créer une politique d'approbation personnalisée pour le rôle afin de limiter l'autorisation à un groupe, un projet, une branche ou un tag spécifique. Pour la liste complète des types de filtrage pris en charge, consultez Se connecter aux services cloud.
Sur GitLab.com, AWS prend en charge des clés de condition supplémentaires pour le fournisseur d'identité OIDC gitlab.com, notamment namespace_id et project_id. Incluez des conditions sur ces identifiants stables et uniques dans vos politiques d'approbation de rôle. Ces identifiants étant indépendants des chemins, les politiques d'approbation qui les référencent ne sont pas affectées par les modifications de chemins, telles que les renommages de groupes ou de projets.
Ces clés de condition supplémentaires sont disponibles uniquement pour le fournisseur d'identité OIDC gitlab.com. Pour GitLab Self-Managed et GitLab Dedicated, seule la revendication sub est actuellement prise en charge en tant que clé de condition AWS. Pour ces déploiements, définissez la portée de votre politique d'approbation en utilisant uniquement sub (par exemple, gitlab.example.com:sub).
project_id est unique au niveau mondial et reste identique pendant toute la durée de vie du projet, y compris lors des renommages de groupes, de projets et des transferts de projets. namespace_id est stable tant que le projet reste dans son espace de nommage actuel. Si le projet est transféré vers un autre espace de nommage, namespace_id change, ce qui invalide intentionnellement une politique d'approbation qui y est rattachée.
Pour trouver les valeurs namespace_id et project_id d'un projet, consultez la page des paramètres du projet ou l'API Projects. Pour la liste complète des revendications disponibles en tant que clés de condition, consultez la section Charge utile du jeton d'ID.
L'exemple de politique d'approbation suivant utilise sub conjointement avec namespace_id et project_id pour ancrer l'approbation à un groupe, un projet et une branche spécifiques sur GitLab.com :
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::AWS_ACCOUNT:oidc-provider/gitlab.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"gitlab.com:sub": "project_path:mygroup/myproject:ref_type:branch:ref:main",
"gitlab.com:namespace_id": "12345",
"gitlab.com:project_id": "67890"
}
}
}
]
}
Une fois le rôle créé, associez une politique définissant les autorisations pour un service AWS (S3, EC2, Secrets Manager).
Après avoir configuré l'OIDC et le rôle, le job GitLab CI/CD peut récupérer des informations d'identification temporaires auprès d'AWS Security Token Service (STS).
assume role:
id_tokens:
GITLAB_OIDC_TOKEN:
aud: https://gitlab.example.com
script:
# this is split out for correct exit code handling
- >
aws_sts_output=$(aws sts assume-role-with-web-identity
--role-arn ${ROLE_ARN}
--role-session-name "GitLabRunner-${CI_PROJECT_ID}-${CI_PIPELINE_ID}"
--web-identity-token ${GITLAB_OIDC_TOKEN}
--duration-seconds 3600
--query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]'
--output text)
- export $(printf "AWS_ACCESS_KEY_ID=%s AWS_SECRET_ACCESS_KEY=%s AWS_SESSION_TOKEN=%s" $aws_sts_output)
- aws sts get-caller-identity
ROLE_ARN : L'ARN du rôle défini dans cette étape.GITLAB_OIDC_TOKEN : Un jeton d'ID OIDC.{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
[!warning] Cette solution de contournement est une option de configuration avancée impliquant des considérations de sécurité à prendre en compte. Vous devez veiller à synchroniser correctement la configuration OpenID et les clés publiques de votre instance GitLab Self-Managed privée vers un emplacement accessible publiquement, tel qu'un bucket S3. Vous devez également vous assurer que le bucket S3 et les fichiers qu'il contient sont correctement sécurisés. Ne pas sécuriser correctement le bucket S3 pourrait entraîner la prise de contrôle de tout compte cloud associé à cette identité OpenID Connect.
Si votre instance GitLab n'est pas accessible publiquement, la configuration d'OpenID Connect dans AWS n'est pas possible par défaut. Vous pouvez utiliser une solution de contournement pour rendre certaines configurations spécifiques accessibles publiquement, permettant ainsi la configuration d'OpenID Connect pour l'instance :
Stockez les détails d'authentification de votre instance GitLab dans un emplacement accessible publiquement, par exemple dans des fichiers S3 :
/.well-known/openid-configuration, comme http://gitlab.example.com/.well-known/openid-configuration. Mettez à jour les valeurs issuer: et jwks_uri: dans le fichier de configuration pour qu'elles pointent vers les emplacements accessibles publiquement./oauth/discovery/keys, comme http://gitlab.example.com/oauth/discovery/keys.Par exemple :
https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com/.well-known/openid-configuration.https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com/oauth/discovery/keys.iss: dans les jetons d'ID et la valeur issuer: dans la configuration OpenID seraient : https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.comfacultatif. Utilisez un validateur de configuration OpenID tel que OpenID Configuration Endpoint Validator pour valider votre configuration OpenID accessible publiquement.
Configurez une revendication d'émetteur personnalisée pour vos jetons d'ID. Par défaut, les jetons d'ID GitLab ont la revendication d'émetteur iss: définie comme l'adresse de votre instance GitLab, par exemple : http://gitlab.example.com.
Mettez à jour l'URL de l'émetteur :
{{< tabs >}}
{{< tab title="Linux package (Omnibus)" >}}
Modifiez /etc/gitlab/gitlab.rb :
gitlab_rails['ci_id_tokens_issuer_url'] = '<public_url_with_openid_configuration_and_keys>'
Remplacez <public_url_with_openid_configuration_and_keys> par une URL telle que https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com.
Enregistrez le fichier et reconfigurez GitLab pour que les modifications prennent effet.
{{< /tab >}}
{{< tab title="Helm chart (Kubernetes)" >}}
Exportez les valeurs Helm :
helm get values gitlab > gitlab_values.yaml
Modifiez gitlab_values.yaml :
global:
appConfig:
ciIdTokens:
issuerUrl: '<public_url_with_openid_configuration_and_keys>'
Remplacez <public_url_with_openid_configuration_and_keys> par une URL telle que https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com.
Enregistrez le fichier et appliquez les nouvelles valeurs :
helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
{{< /tab >}}
{{< tab title="Docker" >}}
Modifiez docker-compose.yml :
version: "3.6"
services:
gitlab:
environment:
GITLAB_OMNIBUS_CONFIG: |
gitlab_rails['ci_id_tokens_issuer_url'] = '<public_url_with_openid_configuration_and_keys>'
Remplacez <public_url_with_openid_configuration_and_keys> par une URL telle que https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com.
Enregistrez le fichier et redémarrez GitLab :
docker compose up -d
{{< /tab >}}
{{< tab title="Self-compiled (source)" >}}
Modifiez /home/git/gitlab/config/gitlab.yml :
production: &base
ci_id_tokens:
issuer_url: '<public_url_with_openid_configuration_and_keys>'
Remplacez <public_url_with_openid_configuration_and_keys> par une URL telle que https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com.
Enregistrez le fichier et reconfigurez GitLab pour que les modifications prennent effet.
{{< /tab >}}
{{< /tabs >}}
Exécutez la tâche Rake ci:validate_id_token_configuration pour valider la configuration du jeton d'ID CI/CD.
Not authorized to perform sts:AssumeRoleWithWebIdentity {#error-not-authorized-to-perform-stsassumerolewithwebidentity}Si vous voyez cette erreur :
An error occurred (AccessDenied) when calling the AssumeRoleWithWebIdentity operation:
Not authorized to perform sts:AssumeRoleWithWebIdentity
Elle peut survenir pour plusieurs raisons :
StringEquals est utilisé à la place de StringLike lors de l'utilisation d'une condition avec caractère générique. Consultez le ticket associé.Could not connect to openid configuration of provider {#could-not-connect-to-openid-configuration-of-provider-error}Après avoir ajouté le fournisseur d'identité dans AWS IAM, vous pourriez obtenir l'erreur suivante :
Your request has a problem. Please see the following details.
- Could not connect to openid configuration of provider: `https://gitlab.example.com`
Cette erreur se produit lorsque l'émetteur du fournisseur d'identité OIDC présente une chaîne de certificats dans le mauvais ordre, ou contient des certificats en double ou supplémentaires.
Vérifiez la chaîne de certificats de votre instance GitLab. La chaîne doit commencer par le domaine ou l'URL de l'émetteur, puis le certificat intermédiaire, et se terminer par le certificat racine. Utilisez cette commande pour examiner la chaîne de certificats, en remplaçant gitlab.example.com par le nom d'hôte de votre GitLab :
echo | /opt/gitlab/embedded/bin/openssl s_client -connect gitlab.example.com:443
Couldn't retrieve verification key from your identity provider {#couldnt-retrieve-verification-key-from-your-identity-provider-error}Vous pourriez recevoir une erreur similaire à :
An error occurred (InvalidIdentityToken) when calling the AssumeRoleWithWebIdentity operation: Couldn't retrieve verification key from your identity provider, please reference AssumeRoleWithWebIdentity documentation for requirementsCette erreur peut être due aux raisons suivantes :
.well_known et jwks_uri du fournisseur d'identité (IdP) ne sont pas accessibles depuis l'internet public..well_known ou au jwks_uri de l'IdP.Comme indiqué dans l'article du Centre de connaissances AWS pour cette erreur, votre instance GitLab doit être accessible publiquement pour que l'URL .well_known et jwks_uri puissent être résolues. Si ce n'est pas possible, par exemple si votre instance GitLab se trouve dans un environnement hors ligne, consultez la procédure pour configurer une instance GitLab non publique