doc-locale/fr-fr/ci/environments/protected_environments.md
{{< details >}}
{{< /details >}}
Les environnements peuvent être utilisés à des fins de test et de production.
Étant donné que les jobs de déploiement peuvent être déclenchés par différents utilisateurs avec différents rôles, il est important de pouvoir protéger des environnements spécifiques des effets des utilisateurs non autorisés.
Par défaut, un environnement protégé garantit que seules les personnes disposant des privilèges appropriés peuvent y déployer, ce qui assure la sécurité de l'environnement.
[!note] Les administrateurs GitLab peuvent utiliser tous les environnements, y compris les environnements protégés.
Pour protéger ou déprotéger un environnement, vous devez disposer au minimum du rôle Maintainer. De plus, pour mettre à jour les attributs de l'environnement tels que external_url, tier ou description, vous devez également figurer dans la liste Autorisés à déployer.
Prérequis :
Pour protéger un environnement :
Dans la barre supérieure, sélectionnez Rechercher ou aller à et trouvez votre projet.
Dans la barre latérale gauche, sélectionnez Paramètres > CI/CD.
Développez Environnements protégés.
Sélectionnez Protéger un environnement.
Dans la liste Environnement, sélectionnez l'environnement que vous souhaitez protéger.
Dans la liste Autorisés à déployer, sélectionnez le rôle, les utilisateurs ou les groupes auxquels vous souhaitez accorder l'accès au déploiement. Gardez à l'esprit que :
Dans la liste Approbateurs, sélectionnez le rôle, les utilisateurs ou les groupes auxquels vous souhaitez accorder l'accès au déploiement. Gardez à l'esprit que :
Dans la section Règles d'approbation :
Sélectionnez Protéger.
L'environnement protégé apparaît désormais dans la liste des environnements protégés.
Vous pouvez également utiliser l'API pour protéger un environnement :
Utilisez un projet avec une CI qui crée un environnement. Par exemple :
stages:
- test
- deploy
test:
stage: test
script:
- 'echo "Testing Application: ${CI_PROJECT_NAME}"'
production:
stage: deploy
when: manual
script:
- 'echo "Deploying to ${CI_ENVIRONMENT_NAME}"'
environment:
name: ${CI_JOB_NAME}
Utilisez l'interface utilisateur pour créer un nouveau groupe. Par exemple, ce groupe s'appelle protected-access-group et a l'ID de groupe 9899826. Notez que le reste des exemples dans ces étapes utilisent ce groupe.
Utilisez l'API pour ajouter un utilisateur au groupe en tant que reporter :
$ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
--data "user_id=3222377&access_level=20" "https://gitlab.com/api/v4/groups/9899826/members"
{"id":3222377,"name":"Sean Carroll","username":"sfcarroll","state":"active","avatar_url":"https://gitlab.com/uploads/-/system/user/avatar/3222377/avatar.png","web_url":"https://gitlab.com/sfcarroll","access_level":20,"created_at":"2020-10-26T17:37:50.309Z","expires_at":null}
Utilisez l'API pour ajouter le groupe au projet en tant que reporter :
$ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
--request POST "https://gitlab.com/api/v4/projects/22034114/share?group_id=9899826&group_access=20"
{"id":1233335,"project_id":22034114,"group_id":9899826,"group_access":20,"expires_at":null}
Utilisez l'API pour ajouter le groupe avec l'accès à l'environnement protégé :
curl --header 'Content-Type: application/json' --request POST --data '{"name": "production", "deploy_access_levels": [{"group_id": 9899826}]}' \
--header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.com/api/v4/projects/22034114/protected_environments"
Le groupe a maintenant accès et peut être consulté dans l'interface utilisateur.
Un utilisateur peut se voir accorder l'accès aux environnements protégés dans le cadre d'une appartenance à un groupe. Les utilisateurs ayant le rôle Reporter ne peuvent se voir accorder l'accès aux environnements protégés qu'avec cette méthode.
Les utilisateurs ayant le rôle Developer peuvent se voir accorder l'accès à un environnement protégé via l'une des méthodes suivantes :
Si l'utilisateur dispose également d'un accès push ou merge vers la branche déployée en production, il bénéficie des privilèges suivants :
Les utilisateurs qui ont accès à un environnement protégé, mais pas d'accès push ou merge vers la branche qui y est déployée, ne bénéficient que de l'accès au déploiement de l'environnement. Les groupes invités ajoutés au projet avec le rôle Reporter apparaissent dans la liste déroulante pour l'accès limité au déploiement.
Pour ajouter un accès limité au déploiement :
Les chargés de maintenance peuvent :
Pour mettre à jour les attributs de l'environnement tels que external_url, tier ou description sur un environnement protégé, l'utilisateur doit également figurer dans la liste Autorisés à déployer.
Lorsqu'un environnement est déprotégé, toutes les entrées d'accès sont supprimées et doivent être saisies à nouveau si l'environnement est de nouveau protégé.
Lorsqu'une règle d'approbation est supprimée, les déploiements précédemment approuvés n'indiquent plus qui a approuvé le déploiement. Les informations sur la personne ayant approuvé un déploiement sont toujours disponibles dans les événements d'audit du projet. Si une nouvelle règle est ajoutée, les déploiements précédents affichent les nouvelles règles sans l'option d'approbation du déploiement. Le ticket 506687 propose d'afficher l'historique complet des approbations des déploiements, même si une règle d'approbation est supprimée.
Pour plus d'informations, consultez Sécurité des déploiements.
En général, les grandes organisations d'entreprise ont une frontière de permissions explicite entre les développeurs et les opérateurs. Les développeurs créent et testent leur code, et les opérateurs déploient et surveillent l'application. Grâce aux environnements protégés au niveau du groupe, les opérateurs peuvent restreindre l'accès des développeurs aux environnements critiques. Les environnements protégés au niveau du groupe étendent les environnements protégés au niveau du projet au niveau du groupe.
Les permissions de déploiement peuvent être illustrées dans le tableau suivant :
| Environnement | Développeur | Opérateur | Catégorie |
|---|---|---|---|
| Développement | Autorisé | Autorisé | Environnement inférieur |
| Tests | Autorisé | Autorisé | Environnement inférieur |
| Staging | Non autorisé | Autorisé | Environnement supérieur |
| Production | Non autorisé | Autorisé | Environnement supérieur |
(Référence : Environnements de déploiement sur Wikipédia)
Contrairement aux environnements protégés au niveau du projet, les environnements protégés au niveau du groupe utilisent le niveau de déploiement comme nom.
Un groupe peut être composé de nombreux environnements de projet avec des noms uniques. Par exemple, Project-A dispose d'un environnement gprd et Project-B d'un environnement Production, ce qui fait que la protection d'un nom d'environnement spécifique ne s'adapte pas bien à l'échelle. En utilisant les niveaux de déploiement, les deux sont reconnus comme le niveau de déploiement production et sont protégés en même temps.
{{< history >}}
group_level_protected_environment_settings_permission. Activé par défaut.{{< /history >}}
Pour maximiser l'efficacité des environnements protégés au niveau du groupe, les appartenances au niveau du groupe doivent être correctement configurées :
testing).Avec cette configuration en place :
Pour protéger un environnement au niveau du groupe, assurez-vous que vos environnements ont le deployment_tier correct défini dans .gitlab-ci.yml.
{{< history >}}
{{< /history >}}
Configurez les environnements protégés au niveau du groupe en utilisant l'API REST.
Les environnements protégés peuvent également être utilisés pour exiger des approbations manuelles avant les déploiements. Consultez Approbations de déploiement pour plus d'informations.
Un utilisateur qui dispose d'un accès limité au déploiement vers les environnements protégés pourrait ne pas être en mesure d'exécuter un job s'il utilise le mot-clé trigger. Cela est dû au fait que le job ne contient pas la définition du mot-clé environment pour associer le job à l'environnement protégé ; par conséquent, le job est reconnu comme un job standard utilisant le modèle d'autorisation CI/CD standard.
Consultez ce ticket pour plus d'informations sur la prise en charge du mot-clé environment avec le mot-clé trigger.