Accueiil
Products
Red Hat OpenShift Service on AWS
4
Les nœuds
2.4. Fournir des données sensibles aux pods en utilisant des secrets

2.4. Fournir des données sensibles aux pods en utilisant des secrets

Ressources supplémentaires

Certaines applications ont besoin d’informations sensibles, telles que les mots de passe et les noms d’utilisateur, que vous ne voulez pas que les développeurs aient.

En tant qu’administrateur, vous pouvez utiliser des objets Secret pour fournir ces informations sans les exposer dans un texte clair.

2.4.1. Comprendre les secrets
Copier lien

Le type d’objet Secret fournit un mécanisme pour contenir des informations sensibles telles que les mots de passe, Red Hat OpenShift Service sur les fichiers de configuration client AWS, les informations d’identification de dépôt privé, etc. Les secrets découplent le contenu sensible des gousses. Il est possible de 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 comprennent:

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 soutenus par des installations temporaires de stockage de fichiers (tmpfs) et ne viennent jamais se reposer sur un nœud.
Les données secrètes peuvent être partagées dans un espace de noms.

Définition d’objets secrets YAML

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque 
data: 
  username: <username> 
  password: <password>
stringData: 
  hostname: myapp.mydomain.com

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque


data:


  username: <username>


  password: <password>
stringData:


  hostname: myapp.mydomain.com

Copy to Clipboard

Toggle word wrap

1: Indique la structure des noms et valeurs clés du secret.
2: Le format autorisé pour les clés dans le champ de données doit respecter les directives de la valeur DNS_SUBDOMAIN dans le glossaire des identifiants Kubernetes.
3: La valeur associée aux clés dans la carte de données doit être encodée base64.
4: Les entrées dans la carte des chaînes de données sont converties en base64 et l’entrée sera automatiquement déplacée sur la carte des données. Ce champ est écrit seulement; la valeur ne sera retournée que via le champ de données.
5: La valeur associée aux touches de la carte stringData est composée de chaînes de texte brut.

Il faut créer un secret avant de créer les gousses qui dépendent de ce secret.

Lors de la création de secrets:

Créez un objet secret avec des données secrètes.
Actualisez le compte de service de la pod pour permettre la référence au secret.
Créer un pod, qui consomme le secret comme variable d’environnement ou comme fichier (en utilisant un volume secret).

2.4.1.1. Les types de secrets
Copier lien

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

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

Kubernetes.io/basic-auth: Utiliser avec l’authentification de base
Kubernetes.io/dockercfg: Utilisez comme une image pull secret
Kubernetes.io/dockerconfigjson: Utilisez comme une image pull secret
Kubernetes.io/service-account-token: Utilisez pour obtenir un jeton API de compte de service existant
Kubernetes.io/ssh-auth: Utilisez avec l’authentification de clé SSH
Kubernetes.io/tls: Utilisation avec les autorités de certification TLS

Indiquez le type : Opaque si vous ne voulez pas de validation, ce qui signifie que le secret ne prétend pas se conformer à une convention pour les noms ou les valeurs clés. Le secret opaque permet des paires de valeurs non structurées qui peuvent contenir des valeurs arbitraires.

Note

Il est possible de spécifier d’autres types arbitraires, tels que example.com/my-secret-type. Ces types ne sont pas imposés côté serveur, mais indiquent que le créateur du secret destiné à se conformer aux exigences clé / valeur de ce type.

Exemple de création de différents types de secrets, voir Comprendre comment créer des secrets.

2.4.1.2. Clés de données secrètes
Copier lien

Les clés secrètes doivent être dans un sous-domaine DNS.

2.4.1.3. Les secrets d’attraction d’image générés automatiquement
Copier lien

Par défaut, Red Hat OpenShift Service sur AWS crée un secret d’attraction d’image pour chaque compte de service.

Note

Avant Red Hat OpenShift Service sur AWS 4.16, un secret de jeton API de compte de service de longue durée a également été généré pour chaque compte de service créé. À partir de Red Hat OpenShift Service sur AWS 4.16, le secret de jetons de compte de service n’est plus créé.

Après la mise à niveau à 4, tous les secrets de jetons de compte de service de longue durée existants ne sont pas supprimés et continueront à fonctionner. Afin d’obtenir des informations sur la détection des jetons API de longue durée qui sont utilisés dans votre cluster ou de les supprimer s’ils ne sont pas nécessaires, consultez l’article Red Hat Knowledgebase des jetons API de compte de service longue durée dans OpenShift Container Platform.

Ce secret d’attraction d’image est nécessaire pour intégrer le registre d’images OpenShift dans le système d’authentification et d’autorisation de l’utilisateur du cluster.

Cependant, si vous n’activez pas la fonction ImageRegistry ou si vous désactivez le registre d’images OpenShift intégré dans la configuration de l’opérateur de registre d’images du cluster, un secret d’attraction d’image n’est pas généré pour chaque compte de service.

Lorsque le registre d’images OpenShift intégré est désactivé sur un cluster qui l’avait précédemment activé, les secrets d’extraction d’images générés précédemment sont supprimés automatiquement.

2.4.2. Comprendre comment créer des secrets
Copier lien

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

Lors de la création de secrets:

Créez un objet secret qui contient les données que vous souhaitez garder secrètes. Les données spécifiques requises pour chaque type secret sont ventilées dans les sections suivantes.

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

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

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
type: Opaque


data:


  username: <username>
  password: <password>
stringData:


  hostname: myapp.mydomain.com
  secret.properties: |
    property1=valueA
    property2=valueB

Copy to Clipboard

Toggle word wrap

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

Les champs de données ou de données sont utilisés, pas les deux.

Actualisez le compte de service de la pod pour faire référence au secret:
Le YAML d’un compte de service qui utilise un secret
```
apiVersion: v1
kind: ServiceAccount
 ...
secrets:
- name: test-secret
```
```
apiVersion: v1
kind: ServiceAccount
 ...
secrets:
- name: test-secret
```
Copy to Clipboard Toggle word wrap

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

JAML d’un pod populant des fichiers dans un volume avec des données secrètes

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
      volumeMounts: 
          - name: secret-volume
            mountPath: /etc/secret-volume 
            readOnly: true 
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret 
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
      volumeMounts:


          - name: secret-volume
            mountPath: /etc/secret-volume


            readOnly: true


      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret


  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

1: Ajoutez un champ volumeMounts à chaque conteneur qui a besoin du secret.
2: Indique un nom de répertoire inutilisé où vous souhaitez que le secret apparaisse. Chaque clé de la carte secrète de données devient le nom de fichier sous MountPath.
3: Fixez-vous à true. Dans l’affirmative, cela ordonne au conducteur de fournir un volume en lecture seule.
4: Indique le nom du secret.

Le YAML d’un pod populant des variables d’environnement avec des données secrètes

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "export" ]
      env:
        - name: TEST_SECRET_USERNAME_ENV_VAR
          valueFrom:
            secretKeyRef: 
              name: test-secret
              key: username
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "export" ]
      env:
        - name: TEST_SECRET_USERNAME_ENV_VAR
          valueFrom:
            secretKeyRef:


              name: test-secret
              key: username
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

1: Indique la variable d’environnement qui consomme la clé secrète.

Le YAML d’une configuration de configuration des variables d’environnement population 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: 
            name: test-secret
            key: username
      from:
        kind: ImageStreamTag
        namespace: openshift
        name: 'cli:latest'

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


            name: test-secret
            key: username
      from:
        kind: ImageStreamTag
        namespace: openshift
        name: 'cli:latest'

Copy to Clipboard

Toggle word wrap

1: Indique la variable d’environnement qui consomme la clé secrète.

2.4.2.1. Les restrictions de création secrète
Copier lien

Afin d’utiliser un secret, un pod doit faire référence au secret. Le secret peut être utilisé avec un pod de trois façons:

De remplir des variables d’environnement pour les conteneurs.
En tant que fichiers dans un volume monté sur un ou plusieurs de ses conteneurs.
En kubelet lorsque vous tirez des images pour le pod.

Les secrets de type de volume écrivent des données dans le conteneur en tant que fichier en utilisant le mécanisme de volume. Les secrets d’image utilisent des comptes de service pour l’injection automatique du secret dans toutes les gousses dans un espace de noms.

Lorsqu’un modèle contient une définition secrète, la seule façon pour le modèle d’utiliser le secret fourni est de s’assurer que les sources de volume secrètes sont validées et que la référence d’objet spécifié pointe réellement vers un objet secret. C’est pourquoi un secret doit être créé avant les pods qui en dépendent. Le moyen le plus efficace de s’assurer que cela est de le faire injecter automatiquement grâce à l’utilisation 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 des pods dans ce même espace de noms.

Les secrets individuels sont limités à 1 Mo de taille. C’est pour décourager la création de grands secrets qui pourraient épuiser la mémoire apiserver et kubelet. Cependant, la création d’un certain nombre de petits secrets pourrait également épuiser la mémoire.

2.4.2.2. Créer un secret opaque
Copier lien

En tant qu’administrateur, vous pouvez créer un secret opaque, qui vous permet de stocker des paires de valeur non structurées qui peuvent contenir des valeurs arbitraires.

Procédure

Créer un objet secret dans un fichier YAML.

À titre d’exemple:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque 
data:
  username: <username>
  password: <password>

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque


data:
  username: <username>
  password: <password>

Copy to Clipboard

Toggle word wrap

1: Indique un secret opaque.

À l’aide de la commande suivante pour créer un objet secret:
```
oc create -f <filename>.yaml
```
```
$ oc create -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap
D’utiliser le secret dans un pod:
1. Actualisez le compte de service de la pod pour faire référence au secret, comme le montre la section « Comprendre comment créer des secrets ».
2. Créez la gousse, qui consomme le secret comme variable d’environnement ou comme fichier (en utilisant un volume secret), comme le montre la section « Comprendre comment créer des secrets ».

Ressources supplémentaires

Comprendre comment créer des secrets

2.4.2.3. Création d’un ancien compte de service secret de jeton
Copier lien

En tant qu’administrateur, vous pouvez créer un secret de jeton de compte de service existant, qui vous permet de distribuer un jeton de compte de service à des applications qui doivent s’authentifier à l’API.

Avertissement

Il est recommandé d’obtenir des jetons de compte de service liés en utilisant l’API TokenRequest au lieu d’utiliser les secrets de jetons de compte de service existants. Il ne faut créer un jeton de service secret que si vous ne pouvez pas utiliser l’API TokenRequest et si l’exposition de sécurité d’un jeton non expirant dans un objet API lisible est acceptable pour vous.

Les jetons de compte de service liés sont plus sûrs que les secrets de jetons de compte de service pour les raisons suivantes:

Les jetons de compte de service liés ont une durée de vie limitée.
Les jetons de compte de service liés contiennent des audiences.
Les jetons de compte de service lié peuvent être liés à des pods ou secrets et les jetons liés sont invalidés lorsque l’objet lié est supprimé.

Les charges de travail sont automatiquement injectées avec un volume projeté pour obtenir un jeton de compte de service lié. Lorsque votre charge de travail a besoin d’un jeton de compte de service supplémentaire, ajoutez un volume projeté supplémentaire dans votre manifeste de charge de travail.

En savoir plus, voir « Configurer les jetons de compte de service lié à l’utilisation de la projection de volume ».

Procédure

Créer un objet secret dans un fichier YAML:

Exemple d’objet secret

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

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


type: kubernetes.io/service-account-token

Copy to Clipboard

Toggle word wrap

1: Indique un nom de compte de service existant. Lorsque vous créez à la fois les objets ServiceAccount et Secret, créez d’abord l’objet ServiceAccount.
2: Indique un secret de jeton de compte de service.

À l’aide de la commande suivante pour créer l’objet Secret:
```
oc create -f <filename>.yaml
```
```
$ oc create -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap
D’utiliser le secret dans un pod:
1. Actualisez le compte de service de la pod pour faire référence au secret, comme le montre la section « Comprendre comment créer des secrets ».
2. Créez la gousse, qui consomme le secret comme variable d’environnement ou comme fichier (en utilisant un volume secret), comme le montre la section « Comprendre comment créer des secrets ».

Ressources supplémentaires

Comprendre comment créer des secrets

2.4.2.4. Créer un secret d’authentification de base
Copier lien

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. Lors de l’utilisation de ce type secret, le paramètre de données de l’objet Secret doit contenir les clés suivantes encodées dans le format base64:

nom d’utilisateur : le nom d’utilisateur pour l’authentification
le mot de passe ou le jeton pour l’authentification

Note

Le paramètre stringData vous permet d’utiliser un contenu texte clair.

Procédure

Créer un objet secret dans un fichier YAML:

Exemple d’objet secret

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

apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth


data:
stringData:


  username: admin
  password: <password>

Copy to Clipboard

Toggle word wrap

1: Indique un secret d’authentification de base.
2: Indique les valeurs d’authentification de base à utiliser.

À l’aide de la commande suivante pour créer l’objet Secret:
```
oc create -f <filename>.yaml
```
```
$ oc create -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap
D’utiliser le secret dans un pod:
1. Actualisez le compte de service de la pod pour faire référence au secret, comme le montre la section « Comprendre comment créer des secrets ».
2. Créez la gousse, qui consomme le secret comme variable d’environnement ou comme fichier (en utilisant un volume secret), comme le montre la section « Comprendre comment créer des secrets ».

Ressources supplémentaires

Comprendre comment créer des secrets

2.4.2.5. Créer un secret d’authentification SSH
Copier lien

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. Lors de l’utilisation de ce type secret, le paramètre de données de l’objet Secret doit contenir l’identifiant SSH à utiliser.

Procédure

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-ssh-auth
type: kubernetes.io/ssh-auth 
data:
  ssh-privatekey: | 
          MIIEpQIBAAKCAQEAulqb/Y ...

apiVersion: v1
kind: Secret
metadata:
  name: secret-ssh-auth
type: kubernetes.io/ssh-auth


data:
  ssh-privatekey: |


          MIIEpQIBAAKCAQEAulqb/Y ...

Copy to Clipboard

Toggle word wrap

1: Indique un secret d’authentification SSH.
2: Indique la paire de clés/valeurs SSH comme identifiants SSH à utiliser.

À l’aide de la commande suivante pour créer l’objet Secret:
```
oc create -f <filename>.yaml
```
```
$ oc create -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap
D’utiliser le secret dans un pod:
1. Actualisez le compte de service de la pod pour faire référence au secret, comme le montre la section « Comprendre comment créer des secrets ».
2. Créez la gousse, qui consomme le secret comme variable d’environnement ou comme fichier (en utilisant un volume secret), comme le montre la section « Comprendre comment créer des secrets ».

Ressources supplémentaires

Comprendre comment créer des secrets

2.4.2.6. Créer un secret de configuration Docker
Copier lien

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 conteneur.

Kubernetes.io/dockercfg. Ce type secret permet de stocker votre fichier de configuration Docker local. Le paramètre de données de l’objet secret doit contenir le contenu d’un fichier .dockercfg codé au format base64.
Kubernetes.io/dockerconfigjson. Ce type secret permet de stocker votre fichier JSON de configuration Docker local. Le paramètre de données de l’objet secret doit contenir le contenu d’un fichier .docker/config.json encodé au format base64.

Procédure

Créer un objet secret dans un fichier YAML.

Exemple d’objet secret de configuration Docker

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

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


data:
  .dockerconfig:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==

Copy to Clipboard

Toggle word wrap

1: Indique que le secret utilise un fichier de configuration Docker.
2: La sortie d’un fichier de configuration Docker codé de base64

Exemple de configuration Docker objet secret JSON

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

apiVersion: v1
kind: Secret
metadata:
  name: secret-docker-json
  namespace: my-project
type: kubernetes.io/dockerconfig


data:
  .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==

Copy to Clipboard

Toggle word wrap

1: Indique que le secret utilise une configuration Docker JSONfile.
2: La sortie d’un fichier Docker codé de base64

La commande suivante vous permet de créer l’objet Secret
```
oc create -f <filename>.yaml
```
```
$ oc create -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap
D’utiliser le secret dans un pod:
1. Actualisez le compte de service de la pod pour faire référence au secret, comme le montre la section « Comprendre comment créer des secrets ».
2. Créez la gousse, qui consomme le secret comme variable d’environnement ou comme fichier (en utilisant un volume secret), comme le montre la section « Comprendre comment créer des secrets ».

Ressources supplémentaires

Comprendre comment créer des secrets

2.4.2.7. Créer un secret à l’aide de la console web
Copier lien

Créez des secrets à l’aide de la console web.

Procédure

Accédez aux charges de travail Secrets.
Cliquez sur Créer à partir de YAML.
1. Éditez le YAML manuellement sur vos spécifications, ou faites glisser et déposez un fichier dans l’éditeur YAML. À titre d’exemple:
  apiVersion: v1 kind: Secret metadata: name: example namespace: <namespace> type: Opaque
  1
  data: username: <base64 encoded username> password: <base64 encoded password> stringData:
  2
  hostname: myapp.mydomain.com
  Copy to Clipboard Toggle word wrap
  1
  Cet exemple spécifie un secret opaque; cependant, vous pouvez voir d’autres types secrets tels que le secret de jeton de compte de service, le secret d’authentification de base, le secret d’authentification SSH, ou un secret qui utilise la configuration Docker.
  2
  Les entrées dans la carte des chaînes de données sont converties en base64 et l’entrée sera automatiquement déplacée sur la carte des données. Ce champ est écrit seulement; la valeur ne sera retournée que via le champ de données.
Cliquez sur Create.
Cliquez sur Ajouter un secret à la charge de travail.
1. Dans le menu déroulant, sélectionnez la charge de travail à ajouter.
2. Cliquez sur Save.

2.4.3. Comprendre comment mettre à jour les secrets
Copier lien

Lorsque vous modifiez la valeur d’un secret, la valeur (utilisée par une gousse déjà en cours d’exécution) ne changera pas dynamiquement. Afin de changer un secret, vous devez supprimer la gousse d’origine et créer un nouveau pod (peut-être avec un PodSpec identique).

La mise à jour d’un secret suit le même flux de travail que le déploiement d’une nouvelle image Container. La commande kubectl roll-update peut être utilisée.

La valeur resourceVersion dans un secret n’est pas spécifiée lorsqu’elle est référencée. Donc, si un secret est mis à jour en même temps que les pods commencent, la version du secret qui est utilisé pour le pod n’est pas définie.

Note

Actuellement, il n’est pas possible de vérifier la version de ressource d’un objet secret qui a été utilisé lors de la création d’un pod. Il est prévu que les pods rapportent ces informations, de sorte qu’un contrôleur puisse redémarrer ceux à l’aide d’une ancienne ressourceVersion. Dans l’intervalle, ne mettez pas à jour les données des secrets existants, mais en créez de nouveaux avec des noms distincts.

2.4.4. Créer et utiliser des secrets
Copier lien

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

Procédure

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>
```
```
$ oc create sa <service_account_name> -n <your_namespace>
```
Copy to Clipboard Toggle word wrap
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> 
  annotations:
    kubernetes.io/service-account.name: "sa-name" 
type: kubernetes.io/service-account-token 
```
```
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
Copy to Clipboard Toggle word wrap
1
<secret_name> par le nom de votre jeton de service secret.
2
Indique un nom de compte de service existant. Lorsque vous créez à la fois les objets ServiceAccount et Secret, créez d’abord l’objet ServiceAccount.
3
Indique un type secret de jeton de compte de service.
Générer le jeton de compte de service en appliquant le fichier:
```
oc apply -f service-account-token-secret.yaml
```
```
$ oc apply -f service-account-token-secret.yaml
```
Copy to Clipboard Toggle word wrap

Bénéficiez du jeton de compte de service du secret en exécutant la commande suivante:

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

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

Copy to Clipboard

Toggle word wrap

Exemple de sortie

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

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

Copy to Clipboard

Toggle word wrap

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

Faites appel à votre jeton de compte de service pour vous authentifier avec l’API de votre cluster:
```
curl -X GET <openshift_cluster_api> --header "Authorization: Bearer <token>"
```
```
$ curl -X GET <openshift_cluster_api> --header "Authorization: Bearer <token>" 
```
1
```
 
```
2
Copy to Clipboard Toggle word wrap
1
<openshift_cluster_api> par l’API OpenShift cluster.
2
<token> par le jeton de compte de service qui est sorti dans la commande précédente.

2.4.5. À propos de l’utilisation de certificats signés avec des secrets
Copier lien

Afin de sécuriser la communication à votre service, vous pouvez configurer Red Hat OpenShift Service sur AWS pour générer une paire de certificats / clé de service signée que vous pouvez ajouter dans un secret dans un projet.

Le service de service de certificat secret est destiné à prendre en charge les applications complexes de middleware qui ont besoin de certificats out-of-the-box. Il a les mêmes paramètres que les certificats de serveur générés par l’outil administrateur pour les nœuds et les maîtres.

La spécification de Service Pod configurée pour un service de service certificats secrets.

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

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


# ...

Copy to Clipboard

Toggle word wrap

1: Indiquez le nom du certificat

D’autres pods peuvent faire confiance aux certificats créés en cluster (qui ne sont signés que pour les noms DNS internes), en utilisant le paquet CA dans le fichier /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt fichier qui est automatiquement monté dans leur pod.

L’algorithme de signature de cette fonctionnalité est x509.SHA256WithRSA. Afin de tourner manuellement, supprimer le secret généré. Création d’un nouveau certificat.

2.4.5.1. Générer des certificats signés pour une utilisation avec des secrets
Copier lien

Afin d’utiliser une paire de certificats/clés signés avec un pod, créer ou modifier le service pour ajouter le service.beta.openshift.io/serving-cert-secret-name annotation, puis ajouter le secret à la pod.

Procédure

Créer un service de service certificat secret:

Editez la spécification Pod pour votre service.

Ajoutez le service.beta.openshift.io/serving-cert-secret-nom annotation avec le nom que vous souhaitez utiliser pour votre secret.

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

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


spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

Copy to Clipboard

Toggle word wrap

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

Créer le service:
```
oc create -f <file-name>.yaml
```
```
$ oc create -f <file-name>.yaml
```
Copy to Clipboard Toggle word wrap

Découvrez le secret pour vous assurer qu’il a été créé:

Consultez la liste de tous les secrets:

oc get secrets

$ oc get secrets

Copy to Clipboard

Toggle word wrap

Exemple de sortie

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

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

Copy to Clipboard

Toggle word wrap

Consultez les détails de votre secret:

oc describe secret my-cert

$ oc describe secret my-cert

Copy to Clipboard

Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

Éditez votre Pod spec avec ce secret.

apiVersion: v1
kind: Pod
metadata:
  name: my-service-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: my-container
      mountPath: "/etc/my-path"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
  volumes:
  - name: my-volume
    secret:
      secretName: my-cert
      items:
      - key: username
        path: my-group/my-username
        mode: 511

apiVersion: v1
kind: Pod
metadata:
  name: my-service-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: my-container
      mountPath: "/etc/my-path"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
  volumes:
  - name: my-volume
    secret:
      secretName: my-cert
      items:
      - key: username
        path: my-group/my-username
        mode: 511

Copy to Clipboard

Toggle word wrap

Lorsqu’il est disponible, votre gousse fonctionnera. Le certificat sera bon pour le service interne DNS nom, <service.name>.<service.namespace>.svc.

La paire de certificats/clés est automatiquement remplacée lorsqu’elle est proche de l’expiration. Afficher la date d’expiration dans le service.beta.openshift.io/expiry annotation sur le secret, qui est au format RFC3339.

Note

Dans la plupart des cas, le nom DNS du service <service.name>.<service.namespace>.svc n’est pas routable à l’extérieur. L’utilisation principale de <service.name>.<service.namespace>.svc est pour la communication intracluster ou intraservice, et avec re-crypter les routes.

2.4.6. Dépannage des secrets
Copier lien

En cas d’échec d’une génération de certificat de service (l’annotation d’erreur service.beta.openshift.io/serving-cert-generation-error annotation contient):

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

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

Copy to Clipboard

Toggle word wrap

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

Effacer le secret:
```
oc delete secret <secret_name>
```
```
$ oc delete secret <secret_name>
```
Copy to Clipboard Toggle word wrap

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-

Copy to Clipboard

Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

Note

La commande supprimant l’annotation a un - après le nom d’annotation à supprimer.

Retour au début

2.4. Fournir des données sensibles aux pods en utilisant des secrets

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Rendre l’open source plus inclusif

À propos de Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links