5.3. Ressources partagées Opérateur de conducteur CSI
En tant qu'administrateur de cluster, vous pouvez utiliser le pilote Shared Resource CSI dans OpenShift Container Platform pour provisionner des volumes éphémères en ligne qui contiennent le contenu des objets Secret ou ConfigMap. De cette façon, les pods et autres types Kubernetes qui exposent les montages de volumes, et les Builds OpenShift Container Platform peuvent utiliser en toute sécurité le contenu de ces objets à travers potentiellement n'importe quel espace de noms dans le cluster. Pour ce faire, il existe actuellement deux types de ressources partagées : une ressource personnalisée SharedSecret pour les objets Secret et une ressource personnalisée SharedConfigMap pour les objets ConfigMap.
Le pilote CSI de ressources partagées est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas leur utilisation en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.
Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.
Pour activer le pilote CSI de ressources partagées, vous devez activer des fonctionnalités à l'aide de portes de fonctionnalités.
5.3.1. À propos du CSI Copier lienLien copié sur presse-papiers!
Les fournisseurs de stockage ont traditionnellement fourni des pilotes de stockage dans le cadre de Kubernetes. Avec la mise en œuvre de l'interface de stockage des conteneurs (CSI), les fournisseurs tiers peuvent à la place fournir des plugins de stockage à l'aide d'une interface standard sans jamais avoir à modifier le code de base de Kubernetes.
Les opérateurs CSI offrent aux utilisateurs d'OpenShift Container Platform des options de stockage, telles que les instantanés de volume, qui ne sont pas possibles avec les plugins de volume dans l'arborescence.
5.3.2. Partager des secrets entre espaces de noms Copier lienLien copié sur presse-papiers!
Pour partager un secret entre les espaces de noms d'un cluster, vous créez une instance de ressource personnalisée (CR) SharedSecret pour l'objet Secret que vous souhaitez partager.
Conditions préalables
Vous devez être autorisé à effectuer les actions suivantes :
-
Créer des instances de la définition de ressource personnalisée (CRD)
sharedsecrets.sharedresource.openshift.ioau niveau d'un cluster. - Gérer les rôles et les liaisons de rôles dans les espaces de noms du cluster afin de contrôler quels utilisateurs peuvent obtenir, répertorier et surveiller ces instances.
-
Gérez les rôles et les liaisons de rôles pour contrôler si le compte de service spécifié par un pod peut monter un volume CSI (Container Storage Interface) qui fait référence à l'instance
SharedSecretCR que vous souhaitez utiliser. - Accédez aux espaces de noms qui contiennent les Secrets que vous souhaitez partager.
Procédure
Créez une instance
SharedSecretCR pour l'objetSecretque vous souhaitez partager entre les espaces de noms du cluster :oc apply -f - <<EOF apiVersion: sharedresource.openshift.io/v1alpha1 kind: SharedSecret metadata: name: my-share spec: secretRef: name: <name of secret> namespace: <namespace of secret> EOF$ oc apply -f - <<EOF apiVersion: sharedresource.openshift.io/v1alpha1 kind: SharedSecret metadata: name: my-share spec: secretRef: name: <name of secret> namespace: <namespace of secret> EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.3. Utilisation d'une instance de SharedSecret dans un pod Copier lienLien copié sur presse-papiers!
Pour accéder à une instance de ressource personnalisée (CR) SharedSecret à partir d'un pod, vous accordez à un compte de service donné des autorisations RBAC pour utiliser cette instance de CR SharedSecret.
Conditions préalables
-
Vous avez créé une instance
SharedSecretCR pour le secret que vous souhaitez partager entre les espaces de noms du cluster. Vous devez être autorisé à effectuer les actions suivantes
- Créer des configurations de construction et démarrer des constructions.
-
Découvrez quelles instances de
SharedSecretCR sont disponibles en entrant la commandeoc get sharedsecretset en obtenant une liste non vide en retour. -
Déterminez si les comptes de service
builderdont vous disposez dans votre espace de noms sont autorisés à utiliser l'instance de CRSharedSecretdonnée. En d'autres termes, vous pouvez exécuteroc adm policy who-can use <identifier of specific SharedSecret>pour voir si le compte de servicebuilderde votre espace de noms est répertorié.
Si aucune des deux dernières conditions préalables de cette liste n'est remplie, créez, ou demandez à quelqu'un de créer, le contrôle d'accès basé sur les rôles (RBAC) nécessaire pour découvrir les instances de SharedSecret CR et permettre aux comptes de service d'utiliser les instances de SharedSecret CR.
Procédure
Accorder à un compte de service donné des autorisations RBAC pour utiliser l'instance
SharedSecretCR dans son pod en utilisantoc applyavec un contenu YAML :NoteActuellement,
kubectletocont une logique de cas spécial codée en dur qui limite le verbeuseaux rôles centrés sur la sécurité des pods. Par conséquent, vous ne pouvez pas utiliseroc create role …pour créer le rôle nécessaire à la consommation des instances CRSharedSecret.oc apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: shared-resource-my-share namespace: my-namespace rules: - apiGroups: - sharedresource.openshift.io resources: - sharedsecrets resourceNames: - my-share verbs: - use EOF$ oc apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: shared-resource-my-share namespace: my-namespace rules: - apiGroups: - sharedresource.openshift.io resources: - sharedsecrets resourceNames: - my-share verbs: - use EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow Créez le site
RoleBindingassocié au rôle en utilisant la commandeoc:oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder
$ oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builderCopy to Clipboard Copied! Toggle word wrap Toggle overflow Accéder à l'instance
SharedSecretCR à partir d'un pod :oc apply -f - <<EOF kind: Pod apiVersion: v1 metadata: name: my-app namespace: my-namespace spec: serviceAccountName: default containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume volumes: - name: my-csi-volume csi: readOnly: true driver: csi.sharedresource.openshift.io volumeAttributes: sharedSecret: my-share EOF$ oc apply -f - <<EOF kind: Pod apiVersion: v1 metadata: name: my-app namespace: my-namespace spec: serviceAccountName: default # containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume volumes: - name: my-csi-volume csi: readOnly: true driver: csi.sharedresource.openshift.io volumeAttributes: sharedSecret: my-share EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.4. Partage d'une carte de configuration entre espaces de noms Copier lienLien copié sur presse-papiers!
Pour partager une carte de configuration entre les espaces de noms d'un cluster, vous créez une instance de ressource personnalisée (CR) SharedConfigMap pour cette carte de configuration.
Conditions préalables
Vous devez être autorisé à effectuer les actions suivantes :
-
Créer des instances de la définition de ressource personnalisée (CRD)
sharedconfigmaps.sharedresource.openshift.ioau niveau d'un cluster. - Gérer les rôles et les liaisons de rôles dans les espaces de noms du cluster afin de contrôler quels utilisateurs peuvent obtenir, répertorier et surveiller ces instances.
- Gérez les rôles et les liaisons de rôles dans les espaces de noms du cluster pour contrôler quels comptes de service dans les pods qui montent votre volume CSI (Container Storage Interface) peuvent utiliser ces instances.
- Accédez aux espaces de noms qui contiennent les Secrets que vous souhaitez partager.
Procédure
Créez une instance CR
SharedConfigMappour la carte de configuration que vous souhaitez partager entre les espaces de noms du cluster :oc apply -f - <<EOF apiVersion: sharedresource.openshift.io/v1alpha1 kind: SharedConfigMap metadata: name: my-share spec: configMapRef: name: <name of configmap> namespace: <namespace of configmap> EOF$ oc apply -f - <<EOF apiVersion: sharedresource.openshift.io/v1alpha1 kind: SharedConfigMap metadata: name: my-share spec: configMapRef: name: <name of configmap> namespace: <namespace of configmap> EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.5. Utilisation d'une instance de SharedConfigMap dans un pod Copier lienLien copié sur presse-papiers!
Prochaines étapes
Pour accéder à une instance de ressource personnalisée (CR) SharedConfigMap à partir d'un pod, vous accordez à un compte de service donné des autorisations RBAC pour utiliser cette instance de CR SharedConfigMap.
Conditions préalables
-
Vous avez créé une instance
SharedConfigMapCR pour la carte de configuration que vous souhaitez partager entre les espaces de noms du cluster. Vous devez être autorisé à effectuer les actions suivantes :
- Créer des configurations de construction et démarrer des constructions.
-
Découvrez quelles instances de
SharedConfigMapCR sont disponibles en entrant la commandeoc get sharedconfigmapset en obtenant une liste non vide en retour. -
Déterminez si les comptes de service
builderdont vous disposez dans votre espace de noms sont autorisés à utiliser l'instance de CRSharedSecretdonnée. En d'autres termes, vous pouvez exécuteroc adm policy who-can use <identifier of specific SharedSecret>pour voir si le compte de servicebuilderde votre espace de noms est répertorié.
Si aucune des deux dernières conditions préalables de cette liste n'est remplie, créez, ou demandez à quelqu'un de créer, le contrôle d'accès basé sur les rôles (RBAC) nécessaire pour découvrir les instances de SharedConfigMap CR et permettre aux comptes de service d'utiliser les instances de SharedConfigMap CR.
Procédure
Accorder à un compte de service donné des autorisations RBAC pour utiliser l'instance
SharedConfigMapCR dans son pod en utilisantoc applyavec un contenu YAML.NoteActuellement,
kubectletocont une logique de cas spécial codée en dur qui limite le verbeuseaux rôles centrés sur la sécurité des pods. Par conséquent, vous ne pouvez pas utiliseroc create role …pour créer le rôle nécessaire à la consommation d'une instance CRSharedConfigMap.oc apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: shared-resource-my-share namespace: my-namespace rules: - apiGroups: - sharedresource.openshift.io resources: - sharedconfigmaps resourceNames: - my-share verbs: - use EOF$ oc apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: shared-resource-my-share namespace: my-namespace rules: - apiGroups: - sharedresource.openshift.io resources: - sharedconfigmaps resourceNames: - my-share verbs: - use EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow Créez le site
RoleBindingassocié au rôle en utilisant la commandeoc:oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder
oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builderCopy to Clipboard Copied! Toggle word wrap Toggle overflow Accéder à l'instance
SharedConfigMapCR à partir d'un pod :oc apply -f - <<EOF kind: Pod apiVersion: v1 metadata: name: my-app namespace: my-namespace spec: serviceAccountName: default containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume volumes: - name: my-csi-volume csi: readOnly: true driver: csi.sharedresource.openshift.io volumeAttributes: sharedConfigMap: my-share EOF$ oc apply -f - <<EOF kind: Pod apiVersion: v1 metadata: name: my-app namespace: my-namespace spec: serviceAccountName: default # containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume volumes: - name: my-csi-volume csi: readOnly: true driver: csi.sharedresource.openshift.io volumeAttributes: sharedConfigMap: my-share EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.6. Limitations supplémentaires du support pour le pilote CSI de ressources partagées Copier lienLien copié sur presse-papiers!
Le pilote CSI de ressources partagées présente les limitations suivantes :
- Le pilote est soumis aux limitations des volumes éphémères en ligne de l'interface de stockage de conteneurs (CSI).
-
La valeur du champ
readOnlydoit êtretrue. Sinon, lors du provisionnement du volume pendant le démarrage du pod, le pilote renvoie une erreur au kubelet. Cette limitation est conforme aux meilleures pratiques proposées pour le pilote CSI Kubernetes en amont afin d'appliquer les étiquettes SELinux aux volumes associés. -
Le pilote ignore le champ
FSTypecar il ne prend en charge que les volumestmpfs. -
Le pilote ignore le champ
NodePublishSecretRef. En revanche, il utiliseSubjectAccessReviewsavec le verbeusepour déterminer si un pod peut obtenir un volume contenant des instances de ressources personnalisées (CR)SharedSecretouSharedConfigMap.
5.3.7. Détails supplémentaires concernant les VolumeAttributes sur les volumes de pods de ressources partagées Copier lienLien copié sur presse-papiers!
Les attributs suivants affectent les volumes de pods de ressources partagées de différentes manières :
-
L'attribut
refreshResourcedans les propriétésvolumeAttributes. -
L'attribut
refreshResourcesdans la configuration du pilote CSI de ressources partagées. -
Les attributs
sharedSecretetsharedConfigMapdans les propriétésvolumeAttributes.
5.3.7.1. L'attribut refreshResource Copier lienLien copié sur presse-papiers!
Le pilote CSI de ressources partagées respecte l'attribut refreshResource dans les propriétés volumeAttributes du volume. Cet attribut détermine si les mises à jour du contenu de l'objet sous-jacent Secret ou ConfigMap sont copiées sur le volume after. Le volume est initialement provisionné dans le cadre du démarrage du pod. La valeur par défaut de refreshResource est true, ce qui signifie que le contenu est mis à jour.
Si la configuration du pilote CSI pour les ressources partagées a désactivé le rafraîchissement des instances de ressources personnalisées (CR) partagées SharedSecret et SharedConfigMap, l'attribut refreshResource dans les propriétés volumeAttribute n'a aucun effet. L'objectif de cet attribut est de désactiver le rafraîchissement pour des montages de volumes spécifiques lorsque le rafraîchissement est généralement autorisé.
5.3.7.2. L'attribut refreshResources Copier lienLien copié sur presse-papiers!
Vous pouvez utiliser un commutateur global pour activer ou désactiver le rafraîchissement des ressources partagées. Ce commutateur est l'attribut refreshResources dans la carte de configuration csi-driver-shared-resource-config pour le pilote CSI de ressources partagées, que vous pouvez trouver dans l'espace de noms openshift-cluster-csi-drivers. Si vous donnez à cet attribut refreshResources la valeur false, aucun des contenus liés aux objets Secret ou ConfigMap stockés dans le volume n'est mis à jour après le provisionnement initial du volume.
L'utilisation de cette configuration du Shared Resource CSI Driver pour désactiver le rafraîchissement affecte tous les montages de volumes de la grappe qui utilisent le Shared Resource CSI Driver, indépendamment de l'attribut refreshResource dans les propriétés volumeAttributes de l'un de ces volumes.
5.3.7.3. Validation des volumeAttributes avant le provisionnement d'un volume de ressources partagées pour un pod Copier lienLien copié sur presse-papiers!
Dans le volumeAttributes d'un volume unique, vous devez définir un attribut sharedSecret ou sharedConfigMap à la valeur d'une instance SharedSecret ou SharedConfigMap CS. Sinon, lorsque le volume est provisionné pendant le démarrage du pod, une validation vérifie le volumeAttributes de ce volume et renvoie une erreur au kubelet dans les conditions suivantes :
-
Les attributs
sharedSecretetsharedConfigMapont tous deux des valeurs spécifiées. -
Les attributs
sharedSecretetsharedConfigMapn'ont pas de valeurs spécifiées. -
La valeur de l'attribut
sharedSecretousharedConfigMapne correspond pas au nom d'une instance CRSharedSecretouSharedConfigMapsur le cluster.
5.3.8. Intégration entre les ressources partagées, Insights Operator et OpenShift Container Platform Builds Copier lienLien copié sur presse-papiers!
L'intégration entre les ressources partagées, Insights Operator et OpenShift Container Platform Builds facilite l'utilisation des abonnements Red Hat (droits RHEL) dans OpenShift Container Platform Builds.
Auparavant, dans OpenShift Container Platform 4.9.x et les versions antérieures, vous deviez importer manuellement vos informations d'identification et les copier dans chaque projet ou espace de noms où vous exécutiez des builds.
Désormais, dans OpenShift Container Platform 4.10 et les versions ultérieures, les Builds OpenShift Container Platform peuvent utiliser les abonnements Red Hat (droits RHEL) en référençant les ressources partagées et la fonction d'accès simple au contenu fournie par Insights Operator :
-
La fonction d'accès simple au contenu importe vos identifiants d'abonnement dans un objet
Secretbien connu. Voir les liens dans la section suivante "Ressources supplémentaires". -
L'administrateur du cluster crée une instance de ressource personnalisée (CR)
SharedSecretautour de cet objetSecretet accorde des autorisations à des projets ou espaces de noms particuliers. En particulier, l'administrateur du cluster donne au compte de servicebuilderla permission d'utiliser cette instance CRSharedSecret. -
Les constructions qui s'exécutent dans ces projets ou espaces de noms peuvent monter un volume CSI qui fait référence à l'instance
SharedSecretCR et à son contenu RHEL.