Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

3.6. Entrées secrets et configuration des cartes

Important

Afin d’éviter que le contenu des secrets d’entrée et de configuration des cartes apparaisse dans les images de conteneurs de sortie de construction, utilisez les volumes de build dans vos stratégies de build Docker et source-à-image.

Dans certains scénarios, les opérations de construction nécessitent des informations d’identification ou d’autres données de configuration pour accéder aux ressources dépendantes, mais il est indésirable que ces informations soient placées dans le contrôle de la source. À cet effet, vous pouvez définir des secrets d’entrée et configurer des cartes d’entrée.

Lors de la création d’une application Java avec Maven, par exemple, vous pouvez configurer un miroir privé de Maven Central ou JCenter accessible par des clés privées. Afin de télécharger des bibliothèques à partir de ce miroir privé, vous devez fournir ce qui suit:

  1. Fichier settings.xml configuré avec l’URL et les paramètres de connexion du miroir.
  2. Clé privée référencée dans le fichier de paramètres, comme ~/.ssh/id_rsa.

« pour des raisons de sécurité, vous ne voulez pas exposer vos informations d’identification dans l’image de l’application.

Cet exemple décrit une application Java, mais vous pouvez utiliser la même approche pour ajouter des certificats SSL dans le répertoire /etc/ssl/certs, les clés API ou les jetons, les fichiers de licence, et plus encore.

3.6.1. C’est quoi un secret?
Copier lien

Le type d’objet Secret fournit un mécanisme pour contenir des informations sensibles telles que les mots de passe, les fichiers de configuration client dédiés OpenShift, les fichiers dockercfg, les informations d’identification de référentiels de source privée, 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.

Définition d’objet secret YAML

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

data:
2 

  username: <username>
3 

  password: <password>
stringData:
4 

  hostname: myapp.mydomain.com
5
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 est ensuite déplacée sur la carte des données automatiquement. Ce champ est écrit seulement. La valeur n’est retournée que par 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.

3.6.1.1. Les propriétés des secrets
Copier lien

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.

3.6.1.2. 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/service-account-token. Utilise un jeton de compte de service.
  • Kubernetes.io/dockercfg. Utilise le fichier .dockercfg pour les informations d’identification Docker requises.
  • Kubernetes.io/dockerconfigjson. Utilise le fichier .docker/config.json pour les informations d’identification Docker requises.
  • Kubernetes.io/auth de base. À utiliser avec l’authentification de base.
  • Kubernetes.io/ssh-auth. Utiliser avec l’authentification de clé SSH.
  • Kubernetes.io/tls. À utiliser avec les autorités de certification TLS.

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

3.6.1.3. Les mises à jour des 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 change pas dynamiquement. Afin de changer un secret, vous devez supprimer la gousse d’origine et créer un nouveau pod, dans certains cas 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 de conteneur. 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, afin 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.

3.6.2. Créer des secrets
Copier lien

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 pod pour permettre la référence au secret.
  • Créez un pod, qui consomme le secret comme variable d’environnement ou comme fichier à l’aide d’un volume secret.

Procédure

  • Afin de créer un objet secret à partir d’un fichier JSON ou YAML, entrez la commande suivante: 

    $ oc create -f <filename>
    Copy to Clipboard Toggle word wrap

    À titre d’exemple, vous pouvez créer un secret à partir de votre fichier local .docker/config.json: 

    $ oc create secret generic dockerhub \
    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson
    Copy to Clipboard Toggle word wrap

    Cette commande génère une spécification JSON du secret nommé dockerhub et crée l’objet.

    Définition d’objet secret YAML Opaque

    apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
    1 
    
data:
  username: <username>
  password: <password>
    Copy to Clipboard Toggle word wrap

    1
    Indique un secret opaque.

    Docker Configuration JSON Fichier Secret Object Définition

    apiVersion: v1
kind: Secret
metadata:
  name: aregistrykey
  namespace: myapps
type: kubernetes.io/dockerconfigjson
    1 
    
data:
  .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
    2
    Copy to Clipboard Toggle word wrap

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

3.6.3. En utilisant des secrets
Copier lien

Après avoir créé des secrets, vous pouvez créer un pod pour référencer votre secret, obtenir des journaux et supprimer le pod.

Procédure

  1. Créez le pod pour faire référence à votre secret en entrant la commande suivante: 

    $ oc create -f <your_yaml_file>.yaml
    Copy to Clipboard Toggle word wrap

  2. Accédez aux journaux en entrant la commande suivante: 

    $ oc logs secret-example-pod
    Copy to Clipboard Toggle word wrap

  3. Effacer le pod en entrant la commande suivante: 

    $ oc delete pod secret-example-pod
    Copy to Clipboard Toggle word wrap

Afin de fournir des informations d’identification et d’autres données de configuration à une compilation sans les placer dans le contrôle source, vous pouvez définir des secrets d’entrée et des cartes de configuration d’entrée.

Dans certains scénarios, les opérations de construction nécessitent des informations d’identification ou d’autres données de configuration pour accéder aux ressources dépendantes. Afin de rendre ces informations disponibles sans le placer dans le contrôle source, vous pouvez définir des secrets d’entrée et des cartes de configuration d’entrée.

Procédure

Ajouter un secret d’entrée, configurer des cartes ou les deux à un objet BuildConfig existant:

  1. Lorsque l’objet ConfigMap n’existe pas, créez-le en entrant la commande suivante: 

    $ oc create configmap settings-mvn \
    --from-file=settings.xml=<path/to/settings.xml>
    Copy to Clipboard Toggle word wrap

    Cela crée une nouvelle carte de configuration nommée settings-mvn, qui contient le contenu en texte brut du fichier settings.xml.

    Astuce

    Alternativement, vous pouvez appliquer le YAML suivant pour créer la carte de configuration: 

    apiVersion: core/v1
kind: ConfigMap
metadata:
  name: settings-mvn
data:
  settings.xml: |
    <settings>
    … # Insert maven settings here
    </settings>
    Copy to Clipboard Toggle word wrap

  2. Dans le cas où l’objet Secret n’existe pas, créez-le en entrant la commande suivante: 

    $ oc create secret generic secret-mvn \
    --from-file=ssh-privatekey=<path/to/.ssh/id_rsa> \
    --type=kubernetes.io/ssh-auth
    Copy to Clipboard Toggle word wrap

    Cela crée un nouveau secret nommé secret-mvn, qui contient le contenu codé de base64 de la clé privée id_rsa.

    Astuce

    Alternativement, vous pouvez appliquer le YAML suivant pour créer le secret d’entrée: 

    apiVersion: core/v1
kind: Secret
metadata:
  name: secret-mvn
type: kubernetes.io/ssh-auth
data:
  ssh-privatekey: |
    # Insert ssh private key, base64 encoded
    Copy to Clipboard Toggle word wrap

  3. Ajoutez la carte de configuration et le secret à la section source de l’objet BuildConfig existant: 

    source:
  git:
    uri: https://github.com/wildfly/quickstart.git
  contextDir: helloworld
  configMaps:
    - configMap:
        name: settings-mvn
  secrets:
    - secret:
        name: secret-mvn
    Copy to Clipboard Toggle word wrap

  4. Afin d’inclure la carte secrète et de configuration dans un nouvel objet BuildConfig, entrez la commande suivante: 

    $ oc new-build \
    openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \
    --context-dir helloworld --build-secret “secret-mvn” \
    --build-config-map "settings-mvn"
    Copy to Clipboard Toggle word wrap

    Au cours de la construction, le processus de construction copie les fichiers settings.xml et id_rsa dans le répertoire où se trouve le code source. Dans OpenShift Dedicated S2I builder images, il s’agit du répertoire de travail d’image, qui est défini à l’aide de l’instruction WORKDIR dans le Dockerfile. Dans le cas où vous souhaitez spécifier un autre répertoire, ajoutez une destinationDir à la définition: 

    source:
  git:
    uri: https://github.com/wildfly/quickstart.git
  contextDir: helloworld
  configMaps:
    - configMap:
        name: settings-mvn
      destinationDir: ".m2"
  secrets:
    - secret:
        name: secret-mvn
      destinationDir: ".ssh"
    Copy to Clipboard Toggle word wrap

    Lorsque vous créez un nouvel objet BuildConfig, vous pouvez également spécifier le répertoire de destination en entrant la commande suivante: 

    $ oc new-build \
    openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \
    --context-dir helloworld --build-secret “secret-mvn:.ssh” \
    --build-config-map "settings-mvn:.m2"
    Copy to Clipboard Toggle word wrap

    Dans les deux cas, le fichier settings.xml est ajouté au répertoire ./.m2 de l’environnement de construction, et la clé id_rsa est ajoutée au répertoire ./.ssh.

3.6.5. La stratégie source à image
Copier lien

Lors de l’utilisation d’une stratégie Source, tous les secrets d’entrée définis sont copiés dans leur destination respectiveDir. Lorsque vous avez laissé destinationDir vide, les secrets sont placés dans le répertoire de travail de l’image du constructeur.

La même règle est utilisée lorsqu’une destinationDir est un chemin relatif. Les secrets sont placés dans les chemins qui sont relatifs au répertoire de travail de l’image. Le répertoire final du chemin destinationDir est créé s’il n’existe pas dans l’image du constructeur. L’ensemble des répertoires précédents de destinationDir doit exister, ou une erreur se produira.

Note

Les secrets d’entrée sont ajoutés sous forme d’écriture mondiale, ont 0666 permissions, et sont tronqués à la taille zéro après l’exécution du script d’assemblage. Cela signifie que les fichiers secrets existent dans l’image résultante, mais ils sont vides pour des raisons de sécurité.

Les cartes de configuration d’entrée ne sont pas tronquées une fois le script d’assemblage terminé.

Retour au début
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. Découvrez nos récentes mises à jour.

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 le Blog 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.

Theme

© 2025 Red Hat