SupportConsoleDéveloppeursCommencer un essaiContact

2.7. Fournir des données sensibles aux pods

Certaines applications nécessitent des informations sensibles, telles que des mots de passe et des noms d'utilisateur, que vous ne voulez pas que les développeurs possèdent.

En tant qu'administrateur, vous pouvez utiliser les objets Secret pour fournir ces informations sans les exposer en clair.

2.7.1. Comprendre les secrets

Le type d'objet Secret fournit un mécanisme pour contenir des informations sensibles telles que les mots de passe, les fichiers de configuration du client OpenShift Container Platform, les informations d'identification du référentiel source privé, etc. Les secrets découplent le contenu sensible des pods. Vous pouvez monter des secrets dans des conteneurs à l'aide d'un plugin de volume ou le système peut utiliser des secrets pour effectuer des actions au nom d'un pod.

Les principales propriétés sont les suivantes

  • Les données secrètes peuvent être référencées indépendamment de leur définition.
  • Les volumes de données secrètes sont sauvegardés par des installations de stockage de fichiers temporaires (tmpfs) et ne s'arrêtent jamais sur un nœud.
  • Les données secrètes peuvent être partagées au sein d'un espace de noms.

YAML Secret définition de l'objet

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque 1
data: 2
  username: dmFsdWUtMQ0K 3
  password: dmFsdWUtMg0KDQo=
stringData: 4
  hostname: myapp.mydomain.com 5

1
Indique la structure des noms et des valeurs des clés du secret.
2
Le format autorisé pour les clés du champ data doit respecter les directives de la valeur DNS_SUBDOMAIN dans le glossaire des identifiants Kubernetes.
3
La valeur associée aux clés de la carte data doit être encodée en base64.
4
Les entrées de la carte stringData sont converties en base64 et l'entrée est alors déplacée automatiquement vers la carte data. Ce champ est en écriture seule ; la valeur ne sera renvoyée que via le champ data.
5
La valeur associée aux clés de la carte stringData est constituée de chaînes de texte en clair.

Vous devez créer un secret avant de créer les modules qui dépendent de ce secret.

Lors de la création de secrets :

  • Créer un objet secret avec des données secrètes.
  • Mettre à jour le compte de service du pod pour autoriser la référence au secret.
  • Créer un pod, qui consomme le secret comme une variable d'environnement ou comme un fichier (en utilisant un volume secret ).

2.7.1.1. Types de secrets

La valeur du champ type indique la structure des noms et des valeurs des clés du secret. Le type peut être utilisé pour imposer la présence de noms d'utilisateur et de clés dans l'objet secret. Si vous ne souhaitez pas de validation, utilisez le type opaque, qui est le type par défaut.

Indiquez l'un des types suivants pour déclencher une validation minimale côté serveur afin de garantir la présence de noms de clés spécifiques dans les données secrètes :

  • kubernetes.io/service-account-token. Utilise un jeton de compte de service.
  • kubernetes.io/basic-auth. Utilisation avec l'authentification de base.
  • kubernetes.io/ssh-auth. Utiliser avec l'authentification par clé SSH.
  • kubernetes.io/tls. A utiliser avec les autorités de certification TLS.

Indiquez type: Opaque si vous ne souhaitez pas de validation, ce qui signifie que le secret ne prétend pas se conformer à une convention pour les noms de clés ou les valeurs. Un secret opaque permet d'utiliser des paires key:value non structurées pouvant contenir des valeurs arbitraires.

Note

Vous pouvez spécifier d'autres types arbitraires, tels que example.com/my-secret-type. Ces types ne sont pas appliqués côté serveur, mais ils indiquent que le créateur du secret avait l'intention de se conformer aux exigences clé/valeur de ce type.

Pour des exemples de différents types de secrets, voir les exemples de code sur Using Secrets.

2.7.1.2. Clés de données secrètes

Les clés secrètes doivent se trouver dans un sous-domaine DNS.

2.7.1.3. À propos des secrets de jetons de compte de service générés automatiquement

Dans la version 4.12, OpenShift Container Platform adopte une amélioration de Kubernetes en amont, qui active la fonctionnalité LegacyServiceAccountTokenNoAutoGeneration par défaut. Par conséquent, lors de la création de nouveaux comptes de service (SA), un secret de jeton de compte de service n'est plus automatiquement généré. Auparavant, OpenShift Container Platform ajoutait automatiquement un jeton de compte de service à un secret pour chaque nouveau SA.

Cependant, certaines fonctionnalités et charges de travail ont besoin de secrets de jetons de compte de service pour communiquer avec le serveur API Kubernetes, par exemple, OpenShift Controller Manager. Cette exigence sera modifiée dans une prochaine version, mais elle demeure dans OpenShift Container Platform 4.12. Par conséquent, si vous avez besoin d'un secret de jeton de compte de service, vous devez utiliser manuellement l'API TokenRequest pour demander des jetons de compte de service liés ou créer un secret de jeton de compte de service.

Après la mise à jour vers la version 4.12, les secrets de jetons de compte de service existants ne sont pas supprimés et continuent de fonctionner comme prévu.

Note

Dans la version 4.12, les secrets des jetons des comptes de service sont toujours générés automatiquement. Au lieu de créer deux secrets par compte de service, OpenShift Container Platform n'en crée plus qu'un. Dans une prochaine version, ce nombre sera encore réduit à zéro. Notez que les secrets dockercfg sont toujours générés et qu'aucun secret n'est supprimé lors des mises à jour.

Ressources supplémentaires

2.7.2. Comprendre comment créer des secrets

En tant qu'administrateur, vous devez créer un secret avant que les développeurs puissent créer les modules qui dépendent de ce secret.

Lors de la création de secrets :

  1. Créez un objet secret contenant les données que vous souhaitez garder secrètes. Les données spécifiques requises pour chaque type de secret sont décrites dans les sections suivantes.

    Exemple d'objet YAML qui crée un secret opaque

    apiVersion: v1
kind: Secret
metadata:
  name: test-secret
type: Opaque 1
data: 2
  username: dmFsdWUtMQ0K
  password: dmFsdWUtMQ0KDQo=
stringData: 3
  hostname: myapp.mydomain.com
  secret.properties: |
    property1=valueA
    property2=valueB

    1
    Spécifie le type de secret.
    2
    Spécifie la chaîne et les données encodées.
    3
    Spécifie la chaîne et les données décodées.

    Utilisez soit le champ data, soit le champ stringdata, mais pas les deux.

  2. Mettre à jour le compte de service du pod pour référencer le secret :

    YAML d'un compte de service qui utilise un secret

    apiVersion: v1
kind: ServiceAccount
 ...
secrets:
- name: test-secret

  3. Créer un pod, qui consomme le secret comme une variable d'environnement ou comme un fichier (en utilisant un volume secret ) :

    YAML d'un pod remplissant les fichiers d'un volume avec des données secrètes

    apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
      volumeMounts: 1
          - name: secret-volume
            mountPath: /etc/secret-volume 2
            readOnly: true 3
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret 4
  restartPolicy: Never

    1
    Ajoutez un champ volumeMounts à chaque conteneur qui a besoin du secret.
    2
    Spécifie un nom de répertoire inutilisé dans lequel vous souhaitez que le secret apparaisse. Chaque clé de la carte de données secrètes devient le nom de fichier sous mountPath.
    3
    Défini à true. S'il est vrai, cela indique au pilote de fournir un volume en lecture seule.
    4
    Spécifie le nom du secret.

    YAML d'un pod remplissant les variables d'environnement avec des données secrètes

    apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "export" ]
      env:
        - name: TEST_SECRET_USERNAME_ENV_VAR
          valueFrom:
            secretKeyRef: 1
              name: test-secret
              key: username
  restartPolicy: Never

    1
    Spécifie la variable d'environnement qui consomme la clé secrète.

    YAML d'une configuration de construction remplissant les variables d'environnement avec des données secrètes

    apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: secret-example-bc
spec:
  strategy:
    sourceStrategy:
      env:
      - name: TEST_SECRET_USERNAME_ENV_VAR
        valueFrom:
          secretKeyRef: 1
            name: test-secret
            key: username

    1
    Spécifie la variable d'environnement qui consomme la clé secrète.

2.7.2.1. Restrictions à la création de secrets

Pour utiliser un secret, un module doit faire référence au secret. Un secret peut être utilisé avec un module de trois façons :

  • Pour remplir les variables d'environnement des conteneurs.
  • En tant que fichiers dans un volume monté sur un ou plusieurs de ses conteneurs.
  • Par kubelet lors de l'extraction des images pour le pod.

Les secrets de type volume écrivent des données dans le conteneur sous forme de fichier en utilisant le mécanisme de volume. Les secrets de type image pull utilisent des comptes de service pour l'injection automatique du secret dans tous les pods d'un espace de noms.

Lorsqu'un modèle contient une définition de secret, le seul moyen pour le modèle d'utiliser le secret fourni est de s'assurer que les sources de volume du secret sont validées et que la référence d'objet spécifiée pointe effectivement vers un objet Secret. Par conséquent, un secret doit être créé avant tout pod qui en dépend. Le moyen le plus efficace de s'en assurer est de l'injecter automatiquement par l'intermédiaire d'un compte de service.

Les objets API secrets résident dans un espace de noms. Ils ne peuvent être référencés que par les pods de ce même espace de noms.

La taille des secrets individuels est limitée à 1 Mo. Il s'agit de décourager la création de secrets volumineux qui pourraient épuiser la mémoire de l'apiserver et du kubelet. Cependant, la création d'un certain nombre de secrets plus petits pourrait également épuiser la mémoire.

2.7.2.2. Création d'un secret opaque

En tant qu'administrateur, vous pouvez créer un secret opaque, qui vous permet de stocker des paires key:value non structurées pouvant contenir des valeurs arbitraires.

Procédure

  1. Créer un objet Secret dans un fichier YAML sur un nœud de plan de contrôle.

    Par exemple : 

    apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque 1
data:
  username: dXNlci1uYW1l
  password: cGFzc3dvcmQ=
    1
    Spécifie un secret opaque.

  2. La commande suivante permet de créer un objet Secret: 

    $ oc create -f <filename>.yaml

  3. Pour utiliser le secret dans une dosette :

    1. Mettez à jour le compte de service du pod pour référencer le secret, comme indiqué dans la section "Comprendre comment créer des secrets".
    2. Créer le pod, qui consomme le secret sous forme de variable d'environnement ou de fichier (à l'aide d'un volume secret ), comme indiqué dans la section "Comprendre comment créer des secrets".

Ressources supplémentaires

2.7.2.3. Création d'un jeton secret de compte de service

En tant qu'administrateur, vous pouvez créer un secret de jeton de compte de service, qui vous permet de distribuer un jeton de compte de service aux applications qui doivent s'authentifier auprès de l'API.

Note

Il est recommandé d'obtenir des jetons de compte de service liés à l'aide de l'API TokenRequest plutôt que d'utiliser des jetons de compte de service secrets. Les jetons obtenus à l'aide de l'API TokenRequest sont plus sûrs que les jetons stockés dans les secrets, car ils ont une durée de vie limitée et ne sont pas lisibles par d'autres clients de l'API.

Vous ne devez créer un secret de jeton de compte de service que si vous ne pouvez pas utiliser l'API TokenRequest et si l'exposition à la sécurité d'un jeton n'expirant pas dans un objet API lisible est acceptable pour vous.

Pour plus d'informations sur la création de jetons de compte de service lié, reportez-vous à la section Ressources supplémentaires.

Procédure

  1. Créer un objet Secret dans un fichier YAML sur un nœud de plan de contrôle :

    Exemple secret objet :

    apiVersion: v1
kind: Secret
metadata:
  name: secret-sa-sample
  annotations:
    kubernetes.io/service-account.name: "sa-name" 1
type: kubernetes.io/service-account-token 2

    1
    Spécifie un nom de compte de service existant. Si vous créez les objets ServiceAccount et Secret, créez d'abord l'objet ServiceAccount.
    2
    Spécifie un secret de jeton de compte de service.

  2. La commande suivante permet de créer l'objet Secret: 

    $ oc create -f <filename>.yaml

  3. Pour utiliser le secret dans une dosette :

    1. Mettez à jour le compte de service du pod pour référencer le secret, comme indiqué dans la section "Comprendre comment créer des secrets".
    2. Créer le pod, qui consomme le secret sous forme de variable d'environnement ou de fichier (à l'aide d'un volume secret ), comme indiqué dans la section "Comprendre comment créer des secrets".

Ressources supplémentaires

2.7.2.4. Création d'un secret d'authentification de base

En tant qu'administrateur, vous pouvez créer un secret d'authentification de base, qui vous permet de stocker les informations d'identification nécessaires à l'authentification de base. Lorsque vous utilisez ce type de secret, le paramètre data de l'objet Secret doit contenir les clés suivantes encodées au format base64 :

  • usernamele nom d'utilisateur pour l'authentification
  • passwordle mot de passe ou le jeton d'authentification
Note

Vous pouvez utiliser le paramètre stringData pour utiliser un contenu en texte clair.

Procédure

  1. Créer un objet Secret dans un fichier YAML sur un nœud de plan de contrôle :

    Exemple d'objet secret 

    apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth 1
data:
stringData: 2
  username: admin
  password: t0p-Secret

    1
    Spécifie un secret d'authentification de base.
    2
    Spécifie les valeurs d'authentification de base à utiliser.

  2. La commande suivante permet de créer l'objet Secret: 

    $ oc create -f <filename>.yaml

  3. Pour utiliser le secret dans une dosette :

    1. Mettez à jour le compte de service du pod pour référencer le secret, comme indiqué dans la section "Comprendre comment créer des secrets".
    2. Créer le pod, qui consomme le secret sous forme de variable d'environnement ou de fichier (à l'aide d'un volume secret ), comme indiqué dans la section "Comprendre comment créer des secrets".

Ressources supplémentaires

2.7.2.5. Création d'un secret d'authentification SSH

En tant qu'administrateur, vous pouvez créer un secret d'authentification SSH, qui vous permet de stocker les données utilisées pour l'authentification SSH. Lorsque vous utilisez ce type de secret, le paramètre data de l'objet Secret doit contenir l'identifiant SSH à utiliser.

Procédure

  1. Créer un objet Secret dans un fichier YAML sur un nœud de plan de contrôle :

    Exemple secret objet :

    apiVersion: v1
kind: Secret
metadata:
  name: secret-ssh-auth
type: kubernetes.io/ssh-auth 1
data:
  ssh-privatekey: | 2
          MIIEpQIBAAKCAQEAulqb/Y ...

    1
    Spécifie un secret d'authentification SSH.
    2
    Spécifie la paire clé/valeur SSH en tant qu'identifiant SSH à utiliser.

  2. La commande suivante permet de créer l'objet Secret: 

    $ oc create -f <filename>.yaml

  3. Pour utiliser le secret dans une dosette :

    1. Mettez à jour le compte de service du pod pour référencer le secret, comme indiqué dans la section "Comprendre comment créer des secrets".
    2. Créer le pod, qui consomme le secret sous forme de variable d'environnement ou de fichier (à l'aide d'un volume secret ), comme indiqué dans la section "Comprendre comment créer des secrets".

Ressources supplémentaires

2.7.2.6. Création d'un secret de configuration Docker

En tant qu'administrateur, vous pouvez créer un secret de configuration Docker, qui vous permet de stocker les informations d'identification pour accéder à un registre d'images de conteneurs.

  • kubernetes.io/dockercfg. Utilisez ce type de secret pour stocker votre fichier de configuration Docker local. Le paramètre data de l'objet secret doit contenir le contenu d'un fichier .dockercfg encodé au format base64.
  • kubernetes.io/dockerconfigjson. Utilisez ce type de secret pour stocker votre fichier JSON de configuration Docker local. Le paramètre data de l'objet secret doit contenir le contenu d'un fichier .docker/config.json encodé au format base64.

Procédure

  1. Créer un objet Secret dans un fichier YAML sur un nœud de plan de contrôle.

    Exemple de configuration Docker secret object

    apiVersion: v1
kind: Secret
metadata:
  name: secret-docker-cfg
  namespace: my-project
type: kubernetes.io/dockerconfig 1
data:
  .dockerconfig:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== 2

    1
    Spécifie que le secret utilise un fichier de configuration Docker.
    2
    La sortie d'un fichier de configuration Docker encodé en base64

    Exemple de configuration Docker JSON secret object

    apiVersion: v1
kind: Secret
metadata:
  name: secret-docker-json
  namespace: my-project
type: kubernetes.io/dockerconfig 1
data:
  .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== 2

    1
    Spécifie que le secret utilise un fichier JSON de configuration Docker.
    2
    La sortie d'un fichier JSON de configuration Docker encodé en base64

  2. La commande suivante permet de créer l'objet Secret 

    $ oc create -f <filename>.yaml

  3. Pour utiliser le secret dans une dosette :

    1. Mettez à jour le compte de service du pod pour référencer le secret, comme indiqué dans la section "Comprendre comment créer des secrets".
    2. Créer le pod, qui consomme le secret sous forme de variable d'environnement ou de fichier (à l'aide d'un volume secret ), comme indiqué dans la section "Comprendre comment créer des secrets".

Ressources supplémentaires

2.7.3. Comprendre comment mettre à jour les secrets

Lorsque vous modifiez la valeur d'un secret, la valeur (utilisée par un pod déjà en cours d'exécution) ne change pas dynamiquement. Pour modifier un secret, vous devez supprimer le module d'origine et en créer un nouveau (éventuellement avec un PodSpec identique).

La mise à jour d'un secret suit le même processus que le déploiement d'une nouvelle image de conteneur. Vous pouvez utiliser la commande kubectl rolling-update.

La valeur resourceVersion d'un secret n'est pas spécifiée lorsqu'il est référencé. Par conséquent, si un secret est mis à jour au moment où les modules démarrent, la version du secret utilisée pour le module n'est pas définie.

Note

Actuellement, il n'est pas possible de vérifier la version de la ressource d'un objet secret qui a été utilisé lors de la création d'un pod. Il est prévu que les modules communiquent cette information, de sorte qu'un contrôleur puisse redémarrer ceux qui utilisent un ancien resourceVersion. Dans l'intervalle, ne mettez pas à jour les données des secrets existants, mais créez-en de nouveaux avec des noms distincts.

2.7.4. Créer et utiliser des secrets

En tant qu'administrateur, vous pouvez créer un jeton de service secret. Cela vous permet de distribuer un jeton de compte de service aux applications qui doivent s'authentifier auprès de l'API.

Procédure

  1. Créez un compte de service dans votre espace de noms en exécutant la commande suivante : 

    $ oc create sa <service_account_name> -n <your_namespace>

  2. Enregistrez l'exemple YAML suivant dans un fichier nommé service-account-token-secret.yaml. L'exemple inclut une configuration d'objet Secret que vous pouvez utiliser pour générer un jeton de compte de service : 

    apiVersion: v1
kind: Secret
metadata:
  name: <secret_name> 1
  annotations:
    kubernetes.io/service-account.name: "sa-name" 2
type: kubernetes.io/service-account-token 3
    1
    Remplacez <secret_name> par le nom de votre jeton de service secret.
    2
    Spécifie un nom de compte de service existant. Si vous créez les objets ServiceAccount et Secret, créez d'abord l'objet ServiceAccount.
    3
    Spécifie un type de secret de jeton de compte de service.

  3. Générer le jeton de compte de service en appliquant le fichier : 

    $ oc apply -f service-account-token-secret.yaml

  4. Obtenez le jeton du compte de service à partir du secret en exécutant la commande suivante : 

    oc get secret <sa_token_secret> -o jsonpath='{.data.token}' | base64 --decode) 1

    Exemple de sortie

    ayJhbGciOiJSUzI1NiIsImtpZCI6IklOb2dtck1qZ3hCSWpoNnh5YnZhSE9QMkk3YnRZMVZoclFfQTZfRFp1YlUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkZXItdG9rZW4tdHZrbnIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiYnVpbGRlciIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjNmZGU2MGZmLTA1NGYtNDkyZi04YzhjLTNlZjE0NDk3MmFmNyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmJ1aWxkZXIifQ.OmqFTDuMHC_lYvvEUrjr1x453hlEEHYcxS9VKSzmRkP1SiVZWPNPkTWlfNRp6bIUZD3U6aN3N7dMSN0eI5hu36xPgpKTdvuckKLTCnelMx6cxOdAbrcw1mCmOClNscwjS1KO1kzMtYnnq8rXHiMJELsNlhnRyyIXRTtNBsy4t64T3283s3SLsancyx0gy0ujx-Ch3uKAKdZi5iT-I8jnnQ-ds5THDs2h65RJhgglQEmSxpHrLGZFmyHAQI-_SjvmHZPXEc482x3SkaQHNLqpmrpJorNqh1M8ZHKzlujhZgVooMvJmWPXTb2vnvi3DGn2XI-hZxl1yD2yGH1RBpYUHA

    1
    Remplacez <sa_token_secret> par le nom de votre jeton de service secret.

  5. Utilisez votre jeton de compte de service pour vous authentifier auprès de l'API de votre cluster : 

    $ curl -X GET <openshift_cluster_api> --header "Authorization : Bearer <token>" 1 2
    1
    Remplacez <openshift_cluster_api> par l'API de cluster OpenShift.
    2
    Remplacez <token> par le jeton de compte de service qui apparaît dans la commande précédente.

2.7.5. Utilisation de certificats signés avec des secrets

Pour sécuriser la communication avec votre service, vous pouvez configurer OpenShift Container Platform pour générer un couple certificat/clé de service signé que vous pouvez ajouter à un secret dans un projet.

Un site service serving certificate secret est destiné à prendre en charge des applications intergicielles complexes qui nécessitent des certificats prêts à l'emploi. Il possède les mêmes paramètres que les certificats de serveur générés par l'outil d'administration pour les nœuds et les maîtres.

Service Pod spec configuré pour un service servant des certificats secrets.

apiVersion: v1
kind: Service
metadata:
  name: registry
  annotations:
    service.beta.openshift.io/serving-cert-secret-name: registry-cert1
# ...

1
Spécifier le nom du certificat

Les autres modules peuvent faire confiance aux certificats créés par le cluster (qui ne sont signés que pour les noms DNS internes), en utilisant le paquet d'autorités de certification dans le fichier /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt qui est automatiquement monté dans leur module.

L'algorithme de signature pour cette fonctionnalité est x509.SHA256WithRSA. Pour effectuer une rotation manuelle, supprimez le secret généré. Un nouveau certificat est créé.

2.7.5.1. Génération de certificats signés à utiliser avec des secrets

Pour utiliser une paire certificat/clé de service signée avec un pod, créez ou modifiez le service pour ajouter l'annotation service.beta.openshift.io/serving-cert-secret-name, puis ajoutez le secret au pod.

Procédure

Pour créer un site service serving certificate secret:

  1. Modifiez la spécification Pod pour votre service.

  2. Ajoutez l'annotation service.beta.openshift.io/serving-cert-secret-name avec le nom que vous voulez utiliser pour votre secret. 

    kind: Service
apiVersion: v1
metadata:
  name: my-service
  annotations:
      service.beta.openshift.io/serving-cert-secret-name: my-cert 1
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

    Le certificat et la clé sont au format PEM et sont stockés respectivement dans tls.crt et tls.key.

  3. Créer le service : 

    oc create -f <nom-de-fichier>.yaml

  4. Consultez le secret pour vous assurer qu'il a bien été créé :

    1. Afficher une liste de tous les secrets : 

      $ oc get secrets

      Exemple de sortie

      NAME                     TYPE                                  DATA      AGE
my-cert                  kubernetes.io/tls                     2         9m

    2. Voir les détails de votre secret : 

      $ oc describe secret my-cert

      Exemple de sortie

      Name:         my-cert
Namespace:    openshift-console
Labels:       <none>
Annotations:  service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z
              service.beta.openshift.io/originating-service-name: my-service
              service.beta.openshift.io/originating-service-uid: 640f0ec3-afc2-4380-bf31-a8c784846a11
              service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z

Type:  kubernetes.io/tls

Data
====
tls.key:  1679 bytes
tls.crt:  2595 bytes

  5. Modifiez votre spécification Pod avec ce secret. 

    apiVersion: v1
kind: Pod
metadata:
  name: my-service-pod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
  volumes:
  - name: foo
    secret:
      secretName: my-cert
      items:
      - key: username
        path: my-group/my-username
        mode: 511

    Lorsqu'il sera disponible, votre pod s'exécutera. Le certificat sera valable pour le nom DNS du service interne, <service.name>.<service.namespace>.svc.

    La paire certificat/clé est automatiquement remplacée lorsqu'elle est proche de l'expiration. La date d'expiration est indiquée dans l'annotation service.beta.openshift.io/expiry sur le secret, au format RFC3339.

    Note

    Dans la plupart des cas, le nom DNS du service <service.name>.<service.namespace>.svc n'est pas routable de l'extérieur. L'utilisation principale de <service.name>.<service.namespace>.svc est pour la communication à l'intérieur d'un cluster ou d'un service, et avec des itinéraires de re-cryptage.

2.7.6. Secrets de dépannage

Si la génération d'un certificat de service échoue avec (l'annotation service.beta.openshift.io/serving-cert-generation-error du service contient) : 

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60

Le service qui a généré le certificat n'existe plus, ou a un autre serviceUID. Vous devez forcer la régénération des certificats en supprimant l'ancien secret et en supprimant les annotations suivantes sur le service service.beta.openshift.io/serving-cert-generation-error, service.beta.openshift.io/serving-cert-generation-error-num:

  1. Supprimer le secret : 

    oc delete secret <secret_name>

  2. Effacer les annotations : 

    oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-
    oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-
Note

La commande de suppression d'une annotation comporte une adresse - après le nom de l'annotation à supprimer.

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.