2.11. Sécuriser les constructions par la stratégie
Les builds dans OpenShift Container Platform sont exécutés dans des conteneurs privilégiés. En fonction de la stratégie de construction utilisée, si vous avez des privilèges, vous pouvez exécuter des constructions pour escalader leurs permissions sur le cluster et les nœuds hôtes. En tant que mesure de sécurité, elle limite les personnes autorisées à exécuter des builds et la stratégie utilisée pour ces builds. Les builds personnalisés sont intrinsèquement moins sûrs que les builds source, car ils peuvent exécuter n'importe quel code dans un conteneur privilégié, et sont désactivés par défaut. Accordez les permissions de construction de docker avec prudence, car une vulnérabilité dans la logique de traitement de Dockerfile pourrait entraîner l'octroi de privilèges sur le nœud hôte.
Par défaut, tous les utilisateurs qui peuvent créer des builds sont autorisés à utiliser les stratégies de build docker et Source-to-image (S2I). Les utilisateurs disposant de privilèges d'administrateur de cluster peuvent activer la stratégie de build personnalisée, comme indiqué dans la section restreignant les stratégies de build à un utilisateur de manière globale.
Vous pouvez contrôler qui peut construire et quelles stratégies de construction ils peuvent utiliser en utilisant une politique d'autorisation. Chaque stratégie de construction a une sous-ressource de construction correspondante. Un utilisateur doit avoir l'autorisation de créer un build et l'autorisation de créer sur la sous-ressource de la stratégie de build pour créer des builds utilisant cette stratégie. Des rôles par défaut sont fournis pour accorder l'autorisation de création sur la sous-ressource de la stratégie de construction.
Stratégie | Sous-ressource | Rôle |
---|---|---|
Docker | builds/docker | system:build-strategy-docker |
De la source à l'image | builds/source | system:build-strategy-source |
Sur mesure | constructions/personnalisées | système:construire-stratégie-personnalisée |
JenkinsPipeline | builds/jenkinspipeline | système:construire-stratégie-jenkinspipeline |
2.11.1. Désactiver l'accès à une stratégie de construction au niveau mondial Copier lienLien copié sur presse-papiers!
Pour empêcher l'accès à une stratégie de construction particulière au niveau mondial, connectez-vous en tant qu'utilisateur disposant de privilèges d'administrateur de cluster, supprimez le rôle correspondant du groupe system:authenticated
et appliquez l'annotation rbac.authorization.kubernetes.io/autoupdate: "false"
pour les protéger contre les modifications entre les redémarrages de l'API. L'exemple suivant montre la désactivation de la stratégie de construction Docker.
Procédure
Appliquez l'annotation
rbac.authorization.kubernetes.io/autoupdate
:oc edit clusterrolebinding system:build-strategy-docker-binding
$ oc edit clusterrolebinding system:build-strategy-docker-binding
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Changez la valeur de l'annotation
rbac.authorization.kubernetes.io/autoupdate
en"false"
.
Supprimer le rôle :
oc adm policy remove-cluster-role-from-group system:build-strategy-docker system:authenticated
$ oc adm policy remove-cluster-role-from-group system:build-strategy-docker system:authenticated
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Assurez-vous que les sous-ressources de la stratégie de construction sont également supprimées de ces rôles :
oc edit clusterrole admin
$ oc edit clusterrole admin
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc edit clusterrole edit
$ oc edit clusterrole edit
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pour chaque rôle, indiquez les sous-ressources qui correspondent à la ressource de la stratégie à désactiver.
Désactiver la stratégie de construction de docker pour admin:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ajoutez
builds/custom
etbuilds/source
pour désactiver globalement les constructions de dockers pour les utilisateurs ayant le rôle admin.
2.11.2. Restreindre les stratégies de construction aux utilisateurs au niveau mondial Copier lienLien copié sur presse-papiers!
Vous pouvez autoriser un ensemble d'utilisateurs spécifiques à créer des builds avec une stratégie particulière.
Conditions préalables
- Désactiver l'accès global à la stratégie de construction.
Procédure
Attribuez le rôle correspondant à la stratégie de construction à un utilisateur spécifique. Par exemple, pour ajouter le rôle de cluster
system:build-strategy-docker
à l'utilisateurdevuser
:oc adm policy add-cluster-role-to-user system:build-strategy-docker devuser
$ oc adm policy add-cluster-role-to-user system:build-strategy-docker devuser
Copy to Clipboard Copied! Toggle word wrap Toggle overflow AvertissementAccorder à un utilisateur l'accès au niveau du cluster à la sous-ressource
builds/docker
signifie que l'utilisateur peut créer des builds avec la stratégie docker dans n'importe quel projet dans lequel il peut créer des builds.
2.11.3. Restreindre les stratégies de construction à un utilisateur au sein d'un projet Copier lienLien copié sur presse-papiers!
De la même manière que vous attribuez le rôle de stratégie de construction à un utilisateur de manière globale, vous pouvez autoriser un ensemble d'utilisateurs spécifiques au sein d'un projet à créer des constructions à l'aide d'une stratégie particulière.
Conditions préalables
- Désactiver l'accès global à la stratégie de construction.
Procédure
Attribuer le rôle correspondant à la stratégie de construction à un utilisateur spécifique au sein d'un projet. Par exemple, pour ajouter le rôle
system:build-strategy-docker
dans le projetdevproject
à l'utilisateurdevuser
:oc adm policy add-role-to-user system:build-strategy-docker devuser -n devproject
$ oc adm policy add-role-to-user system:build-strategy-docker devuser -n devproject
Copy to Clipboard Copied! Toggle word wrap Toggle overflow