30.3. Injection de certificats à l'aide d'opérateurs


Une fois que votre certificat d'autorité de certification personnalisé est ajouté au cluster via ConfigMap, l'opérateur du réseau de clusters fusionne les certificats d'autorité de certification fournis par l'utilisateur et les certificats d'autorité de certification du système en un seul paquet et injecte le paquet fusionné dans l'opérateur qui demande l'injection du paquet de confiance.

Important

Après l'ajout d'un label config.openshift.io/inject-trusted-cabundle="true" à la carte de configuration, les données existantes sont supprimées. L'opérateur du réseau de clusters devient propriétaire d'une carte de configuration et n'accepte que ca-bundle comme données. Vous devez utiliser une carte de configuration séparée pour stocker service-ca.crt en utilisant l'annotation service.beta.openshift.io/inject-cabundle=true ou une configuration similaire. L'ajout d'un label config.openshift.io/inject-trusted-cabundle="true" et d'une annotation service.beta.openshift.io/inject-cabundle=true sur la même carte de configuration peut entraîner des problèmes.

Les opérateurs demandent cette injection en créant un ConfigMap vide avec l'étiquette suivante :

config.openshift.io/inject-trusted-cabundle="true"

Exemple de ConfigMap vide :

apiVersion: v1
data: {}
kind: ConfigMap
metadata:
  labels:
    config.openshift.io/inject-trusted-cabundle: "true"
  name: ca-inject 1
  namespace: apache
1
Spécifie le nom du ConfigMap vide.

L'opérateur monte cette ConfigMap dans le magasin de confiance local du conteneur.

Note

L'ajout d'un certificat d'autorité de certification de confiance n'est nécessaire que si le certificat n'est pas inclus dans l'ensemble de confiance de Red Hat Enterprise Linux CoreOS (RHCOS).

L'injection de certificats n'est pas limitée aux opérateurs. L'opérateur de réseau en grappe injecte des certificats dans n'importe quel espace de noms lorsqu'un ConfigMap vide est créé avec l'étiquette config.openshift.io/inject-trusted-cabundle=true.

Le ConfigMap peut résider dans n'importe quel espace de noms, mais il doit être monté en tant que volume sur chaque conteneur d'un pod nécessitant une autorité de certification personnalisée. Par exemple, le ConfigMap peut se trouver dans n'importe quel espace de noms :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-example-custom-ca-deployment
  namespace: my-example-custom-ca-ns
spec:
  ...
    spec:
      ...
      containers:
        - name: my-container-that-needs-custom-ca
          volumeMounts:
          - name: trusted-ca
            mountPath: /etc/pki/ca-trust/extracted/pem
            readOnly: true
      volumes:
      - name: trusted-ca
        configMap:
          name: trusted-ca
          items:
            - key: ca-bundle.crt 1
              path: tls-ca-bundle.pem 2
1
ca-bundle.crt est nécessaire comme clé du ConfigMap.
2
tls-ca-bundle.pem est requis comme chemin d'accès au ConfigMap.
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.