Configuration de contraintes de contexte de sécurité

Les contraintes de contexte de sécurité (SCC) vous permettent de contrôler les actions et les accès que les pods de votre cluster Red Hat® OpenShift® on IBM Cloud® peuvent effectuer. Pour plus d'informations sur les SCC, consultez la Red Hat OpenShift documentation.

Pourquoi est-ce que je définis des contraintes de contexte de sécurité?
En tant qu'administrateur de cluster, vous désirez contrôler ce qui se passe dans votre cluster, notamment les actions qui affectent la sécurité ou la réactivité du cluster. Ces contraintes de contexte de sécurité peuvent vous aider à contrôler les actions et les accès des pods dans votre conteneur, par exemple, l'utilisation des conteneurs privilégiés, des espaces de noms racine, des réseaux et ports d'hôte, des types de volume, des systèmes de fichiers hôte, des droits Linux, tels que lecture seule ou ID de groupes, etc.
Puis-je également ajouter des utilisateurs ou des groupes système aux SCC?
Pour accéder à vos ressources de cluster, n'utilisez pas SCC. A la place, consultez Affectation d'accès au cluster pour définir les droits d'infrastructure et IAM IBM Cloud.
Pour les groupes de systèmes tels que system:authenticated, ces groupes sont déjà affectés à des contraintes de contexte de sécurité. Vous pouvez voir quels groupes sont affectés à une contrainte de contexte de sécurité en décrivant cette dernière. Si vous modifiez la contrainte de contexte de sécurité à laquelle un groupe de systèmes est affecté, des erreurs peuvent se produire sur les composants par défaut qui appartiennent au groupe de systèmes en raison de la modification des droits.
Y a-t-il des SCC définis par défaut?
Par défaut, les clusters Red Hat OpenShift on IBM Cloud incluent un ensemble standard de contraintes de contexte de sécurité (SCC) Red Hat OpenShift. De plus, les clusters disposent de SCC « IBM » qui ressemblent étroitement aux politiques de sécurité des pods « Kubernetes » des clusters communautaires Kubernetes disponibles sur IBM Cloud Kubernetes Service. Ces contraintes de contexte de sécurité IBM sont incluses pour offrir une meilleure portabilité avec des packages IBM Cloud Private, tels que les packages Cloud Pak.
Quels SCC sont appliqués par défaut à mes ressources?
Si vous ne spécifiez pas de contexte de sécurité, la contrainte de contexte de sécurité Red Hat OpenShift restricted (ou restricted-v2 dans 4.11 et versions ultérieures) est appliquée par défaut. Pour vérifier le contexte de sécurité d'un pod, décrivez ce dernier et recherchez l'annotation de contrainte de contexte de sécurité, comme dans l'exemple suivant :
oc describe pod <pod_name>

Name:               <pod_name>
Namespace:          <project_name>
...
Annotations:        openshift.io/...
                    openshift.io/scc=restricted
...
Puis-je utiliser à la place les politiques de sécurité des pods d' Kubernetes?
Non. Les politiques de sécurité de podKubernetes (PSP) sont à l'origine basées sur des contraintes de contexte de sécurité Red Hat OpenShift. Toutefois, Red Hat OpenShift ne prend en charge que les contraintes de contexte de sécurité et pas les politiques de sécurité de pod.

Les contraintes de contexte de sécurité Red Hat OpenShift par défaut sont plus strictes que les politiques de sécurité de pod par défaut dans les clusters de communauté Kubernetes. Ainsi, il peut s'avérer nécessaire de modifier les déploiements d'application qui s'exécutent dans des clusters de communauté Kubernetes pour permettre leur exécution dans Red Hat OpenShift.

Personnalisation des contraintes de contexte de sécurité

Pour créer, modifier, répertorier, supprimer et gérer les contraintes de contexte de sécurité, consultez la Red Hat OpenShift documentation. Vous pouvez également autoriser des utilisateurs ou des groupes à utiliser les contraintes de contexte de sécurité par défaut à l'aide du contrôle d'accès basé sur les rôles, tel que clusterroles, clusterrolebindings, roles et rolebindings. Vous pouvez également utiliser les sous-commandes oc adm policy, telles que oc adm policy add-scc-to-user, pour gérer ces paramètres. La version oc est la même que celle du cluster en cours de gestion.

Instructions pour l'affectation de l'accès aux contraintes de contexte de sécurité

  • Autorisez des comptes de service spécifiques à la contrainte de contexte de sécurité qui doit être utilisée par les pods s'exécutant sous ce compte de service.
  • Si un compte de service a besoin d'accéder à plusieurs contraintes de contexte de sécurité, envisagez de créer des comptes de service supplémentaires afin que tous les pods exécutés sous un compte de service utilisent la même contrainte de contexte de sécurité.
  • N'autorisez pas tous les utilisateurs ou tous les comptes de service à utiliser des SCC autres que les SCC restricted (4.10 et versions antérieures) ou restricted-v2 (4.11 et versions ultérieures).
  • Ne modifiez pas l'autorisation SCC pour les comptes de service dans les espaces de nom openshift-*. Les composants Red Hat OpenShift sont conçus pour s'exécuter sous des contraintes de contexte de sécurité spécifiques et peuvent ne pas fonctionner correctement sous une contrainte de contexte de sécurité différente.

Contraintes de contexte de sécurité Red Hat OpenShift par défaut

Par défaut, les clusters Red Hat OpenShift on IBM Cloud sont fournis avec les contraintes de contexte de sécurité suivantes.

N'éditez pas les paramètres de contrainte de contexte de sécurité Red Hat OpenShift ou IBM existants, à l'exception des zones priority, users ou groups.

Contraintes de contexte de sécurité Red Hat OpenShift par défaut
Nom de contrainte de contexte de sécurité Description
anyuid Refuse l'accès à la manière de la contrainte de contexte de sécurité restricted, mais permet aux utilisateurs de s'exécuter avec n'importe quel ID utilisateur et n'importe quel ID groupe.
hostaccess Autorise l'accès à tous les espaces de noms d'hôte, mais exige toujours que les pods soient exécutés avec un ID utilisateur et un contexte SELinux qui sont alloués à l'espace de noms.

Important: Accorder ce SCC pour uniquement les gousses de confiance qui requièrent l'accès de l'hôte aux espaces de nom, aux systèmes de fichiers et aux ID de processus.
hostmount-anyuid Refuse l'accès à la manière de la contrainte de contexte de sécurité restricted, mais autorise les montages d'hôte et l'utilisation de n'importe quel ID utilisateur par un pod. Cette contrainte de contexte de sécurité est principalement utilisée par le programme de recyclage de volume persistant.

Important : Accorder ce SCC pour les gousses qui requièrent l'accès au système de fichiers hôte comme n'importe quel ID utilisateur, y compris l'UID 0.
hostnetwork Autorise l'utilisation des réseaux et ports d'hôte, mais exige toujours que les pods soient exécutés avec un ID utilisateur et un contexte SELinux qui sont alloués à l'espace de noms.

Important : Accorde ce SCC uniquement pour les cabosses nécessitant l'accès au réseau hôte.
node-exporter Fournit l'accès approprié pour l'exportateur de noeud Prometheus intégré.
nonroot Refuse l'accès à la manière de la contrainte de contexte de sécurité restricted, mais permet aux utilisateurs de s'exécuter avec n'importe quel ID utilisateur non root. L'utilisateur ou le manifeste de l'environnement d'exécution du conteneur doit spécifier l'ID utilisateur.
privileged Permet d'accéder à toutes les fonctionnalités privilégiées et liées à l'hôte, ainsi que d'exécuter des commandes en tant que n'importe quel utilisateur, n'importe quel groupe, avec n'importe quel paramètre « fsGroup » et dans n'importe quel contexte SELinux.

Important: n'attribuez ce SCC qu'aux administrateurs de cluster qui ont besoin d'un accès aussi étendu que possible.
restricted Refuse l'accès à toutes les fonctions hôte et exige que les pods soient exécutés avec un ID utilisateur et un contexte SELinux qui sont alloués à l'espace de noms. Il s'agit des contraintes de contexte de sécurité les plus restrictives ; elles sont utilisées par défaut pour les utilisateurs authentifiés.
hostnetwork-v2 Similaire à la contrainte de contexte de sécurité hostnetwork, mais modifiée pour réduire les différences du profil Pod Security Standards Restricted.
nonroot-v2 Similaire à la contrainte de contexte de sécurité nonroot, mais modifiée pour réduire les différences du profil Pod Security Standards Restricted.
restricted-v2 Similaire à la contrainte de contexte de sécurité restricted, mais modifiée pour satisfaire le profil Pod Security Standards Restricted.

Contraintes de contexte de sécurité IBM par défaut

Par défaut, les clusters Red Hat OpenShift on IBM Cloud sont fournis avec les contraintes de contexte de sécurité IBM suivantes.

N'éditez pas les paramètres de contrainte de contexte de sécurité Red Hat OpenShift ou IBM existants, à l'exception des zones priority, users ou groups.

Contraintes de contexte de sécurité IBM par défaut
Nom de contrainte de contexte de sécurité Description
ibm-anyuid-hostaccess-scc Permet aux pods de s'exécuter avec n'importe quel ID utilisateur et ID groupe, n'importe quel volume et un accès complet à l'hôte.

Important : Accorde ce SCC uniquement pour les cabosses nécessitant un accès complet à l'hôte et au réseau.
ibm-anyuid-hostpath-scc Permet aux pods de s'exécuter avec n'importe quel ID utilisateur et ID groupe et n'importe quel volume, y compris le chemin d'hôte.

Important : Accorde ce SCC uniquement pour les cabosses nécessitant l'accès aux volumes hostPath.
ibm-anyuid-scc Permet aux pods de s'exécuter avec n'importe quel ID utilisateur et ID groupe, mais empêche l'accès à l'hôte.
ibm-privileged-scc Autorise l'accès à toutes les fonctionnalités d'hôte privilégiées et permet à un pod de s'exécuter avec n'importe quel ID utilisateur et ID groupe et n'importe quel volume.

Important : Accorder ce SCC pour uniquement l'administration de cluster qui requiert le plus d'accès possible.
ibm-restricted-scc Refuse l'accès à toutes les fonctions hôte et exige que les pods soient exécutés avec un ID utilisateur et un contexte SELinux qui sont alloués à l'espace de noms. Il s'agit de la contrainte de contexte de sécurité IBM la plus restrictive.