Gestion des secrets et des certificats TLS et non TLS

Découvrez comment utiliser des certificats et des secrets dans votre cluster.

Envisagez d'utiliser Secrets Manager pour gérer et mettre à jour automatiquement vos secrets de manière centralisée.

Gestion des secrets et des certificats TLS avec Ingress

Votre certificat TLS Ingress est stocké en tant que secret Kubernetes. Pour gérer les secrets TLS dans votre cluster, vous pouvez utiliser le jeu de commandes 'ibmcloud oc ingress secret

Par exemple, vous pouvez importer un certificat de Secrets Manager vers un secret Kubernetes dans votre cluster en exécutant la commande suivante.

ibmcloud oc ingress secret create --cluster <cluster_name_or_ID> --cert-crn <crn> --name <secret_name> --namespace openshift-ingress

Pour importer le certificat à l'aide de la commande ibmcloud oc ingress secret create, vous devez disposer d'une instance par défaut Secrets Manager enregistrée dans votre cluster. Si vous ne disposez pas d'une instance Secrets Manager et que vos secrets sont écrits directement dans votre cluster, vos secrets n'ont pas la valeur CRN requise et vous devez les copier manuellement à l'aide des oc commandes de plug-in OpenShift.

Pour afficher tous les secrets Ingress pour les certificats TLS dans votre cluster, exécutez la commande suivante.

ibmcloud oc ingress secret ls -c <cluster>

Configuration de secrets TLS pour le sous-domaine Ingress fourni par IBM

IBM fournit un sous-domaine Ingress et un certificat TLS par défaut, stockés en tant que secret Kubernetes dans votre cluster, que vous pouvez spécifier dans votre ressource Ingress. Les certificats TLS fournis par IBM sont signés par LetsEncrypt et sont entièrement gérés par IBM.

Le caractère générique du sous-domaine Ingress IBM, *.<cluster_name>.<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud, est enregistré par défaut pour votre cluster. Le certificat TLS fourni par IBM est un certificat générique pouvant être utilisé pour le sous-domaine générique.

Suivez les étapes pour utiliser le certificat TLS par défaut pour le sous-domaine Ingress fourni par IBM.

Obtenez le nom du secret dans lequel votre certificat TLS par défaut est stocké. Notez qu'il s'agit du nom de secret que vous spécifiez dans la section spec.tls de votre ressource Ingress.
```
ibmcloud oc cluster get -c <cluster> | grep Ingress
```
Exemple de sortie
```
Ingress Subdomain:      mycluster-<hash>-0000.us-south.containers.appdomain.cloud
Ingress Secret:         mycluster-<hash>-0000
```
Affichez les détails du secret et notez la valeur CRN. Il s'agit du CRN du certificat TLS. Si vous ne disposez pas d'une instance par défaut [Secrets Manager] enregistrée dans votre cluster, votre secret n'a pas de CRN. Pour plus de détails, reportez-vous à la remarque de l'étape suivante.
```
ibmcloud oc ingress secret get -c <cluster> --name <secret_name> --namespace openshift-ingress
```
Créez un secret pour le certificat TLS par défaut dans chaque espace de nom où se trouvent vos ressources ou applications Ingress. Spécifiez le CRN du certificat TLS avec l'option de commande --cert-crn.
```
ibmcloud oc ingress secret create --cluster <cluster_name_or_ID> --cert-crn <CRN> --name <secret_name> --namespace openshift-ingress
```
Pour copier le secret à l'aide de la commande ibmcloud oc ingress secret create, vous devez disposer d'une instance Secrets Manager par défaut enregistrée dans votre cluster. Si vous ne disposez pas d'une instance Secrets Manager et que vos secrets sont écrits directement dans votre cluster, vos secrets n'ont pas la valeur CRN requise et vous devez les copier manuellement à l'aide des oc commandes de plug-in OpenShift.

Configuration des secrets TLS pour les sous-domaines personnalisés

Si vous définissez un sous-domaine personnalisé, vous pouvez utiliser votre propre certificat TLS pour gérer la terminaison TLS. Vous devez créer un secret Kubernetes pour stocker le certificat TLS, puis importer ce secret dans chaque espace de nom où se trouvent vos applications.

En stockant des certificats TLS personnalisés dans Secrets Manager, vous pouvez importer vos certificats directement dans un secret Kubernetes dans votre cluster.

Créez ou importez un secret pour le certificat TLS dans l'espace de nom où se trouve votre ressource Ingress. Par exemple, vous pouvez importer un secret depuis Secrets Manager dans votre cluster en exécutant la commande suivante. Spécifiez le CRN du certificat TLS avec l'option de commande --cert-crn.

Pour importer le certificat à l'aide de la commande ibmcloud oc ingress secret create, vous devez disposer d'une instance par défaut Secrets Manager enregistrée dans votre cluster. Si vous ne disposez pas d'une instance Secrets Manager et que vos secrets sont écrits directement dans votre cluster, vos secrets n'ont pas la valeur CRN requise et vous devez les copier manuellement à l'aide des oc commandes de plug-in OpenShift.
```
ibmcloud oc ingress secret create --name <secret_name> --cluster <cluster_name_or_ID> --cert-crn <certificate_crn> --namespace openshift-ingress
```
Répétez l'étape précédente pour chaque espace de nom dans lequel se trouvent vos applications.

Gestion des secrets non TLS

Pour gérer des secrets non TLS, vous pouvez utiliser les commandes ibmcloud oc ingress secret.

Il existe 4 types de secrets non TLS:

Les secrets arbitraires contiennent une valeur de chaîne.
Les données d'identification IAM contiennent une clé d'API IAM.
Les secrets de nom d'utilisateur et de mot de passe contiennent un nom d'utilisateur et un mot de passe comme deux valeurs distinctes.
Les valeurs de clé contiennent des valeurs JSON.

Découvrez comment gérer de manière centralisée vos secrets non TLS avec IBM Cloud Secrets Manager. Avec Secrets Manager, vous pouvez créer des secrets Kubernetes gérés, mettre à jour vos secrets automatiquement, créer des groupes de secrets qui contrôlent qui a accès aux secrets de votre cluster, etc.

Création d'un secret non TLS dans votre cluster

Créez un secret non TLS en spécifiant l'option --type Opaque dans la commande ibmcloud oc ingress secret create. Avec le type Opaque, vous pouvez inclure plusieurs valeurs CRN non-certificat. Si l'option " --type n'est pas spécifiée, TLS est appliqué par défaut. Pour plus d'informations et des options de commande supplémentaires, voir Référence de l'interface de ligne de commande.

L'exemple de commande suivant crée un secret non TLS avec le type Opaque spécifié. Les secrets non TLS requièrent au moins une valeur confidentielle zone. Notez que la façon dont vous spécifiez l'option --field varie en fonction du type de secret que vous créez.

ibmcloud oc ingress secret create -c cluster-test --name example-secret --namespace openshift-ingress --field crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa1a11111aaa1a1111aa1aa111:111a1111-11a1 --type Opaque

Pour vérifier que le secret est créé, répertoriez tous les secrets de l'espace de nom.

kubectl get secret -n default

L'exemple suivant montre la sortie.

NAME                   TYPE                                  DATA   AGE
all-icr-io             kubernetes.io/dockerconfigjson        1      41h
default-token-8t6xw    kubernetes.io/service-account-token   3      41h
example-secret         Opaque                                        3m

Gestion des zones de secret non TLS

Une zone de secret est une paire clé-valeur qui est stockée dans un secret non TLS. Reportez-vous aux exemples suivants pour afficher, ajouter, mettre à jour ou supprimer des zones de secret non TLS.

Affichage des valeurs de zone

Vous pouvez afficher les valeurs des zones d'un secret en obtenant les détails du secret.

kubectl get secret -n default example-secret -o yaml

L'exemple de sortie suivant montre les zones de secret et leurs valeurs dans la section data.

apiVersion: v1
data:
  arbitraryFVT: AAAaaAAaAAA1AAAaaAAa
  userCredsFVT_password: aAAaa1aaaA=
  userCredsFVT_username: aAAaaa==
kind: Secret
metadata:
  annotations:
    ingress.cloud.ibm.com/cert-source: ibm
    razee.io/build-url: https://travis.ibm.com/alchemy-containers/armada-ingress-secret-mgr/builds/78876583
    razee.io/source-url: https://github.ibm.com/alchemy-containers/armada-ingress-secret-mgr/commit/651fa822632128163cf638c47f0a14b1e0e2915a
  creationTimestamp: "2022-11-08T19:45:05Z"
  name: example-secret
  namespace: default
  resourceVersion: "111111"
  uid: 1aaa1111-1a11-111a-a1a1-11111a1a1a1a
type: Opaque

Vous pouvez également répertorier les zones d'un secret à l'aide des commandes ibmcloud oc ingress secret field ls et ibmcloud oc ingress secret get, mais les sorties incluent uniquement le nom de la zone et non la valeur qui lui est associée.

Ajout d'une zone de secret

Ajoutez une zone de secret à un secret non TLS en exécutant la commande ibmcloud oc ingress secret field add avec l'option --field. Vous pouvez également utiliser cette option pour ajouter des zones lorsque vous créez un secret à l'aide de la commande ibmcloud oc ingress secret create. Cette option n'est pas prise en charge pour les secrets TLS.

Il existe trois façons de spécifier l'option --field. Celle que vous choisissez dépend du type de secret et de la façon dont vous souhaitez nommer la zone dans le secret.

Options d'ajout de zones à des secrets non TLS
Option	Format	Description	Types de secret pris en charge
Valeur par défaut	`--field <crn>`	Le nom de la zone ajoutée est le nom de zone par défaut pour le type de secret du CRN donné.	Tous les types de secret non TLS
nommée	`--field <name>=<crn>`	Cette option permet d'indiquer un nom pour la zone ajoutée. Le nom de la zone ajoutée est la valeur spécifiée pour `<name>`.	arbitraire - Informations d'identification IAM
Préfixé	`--field prefix=<crn>`	Le nom de la zone ajoutée est le nom de zone par défaut pour le type de secret spécifié par le CRN donné, précédé du nom du secret spécifié par `<crn>` et d'un trait de soulignement.	-Données d'identification IAM -username / password -key/value

Les noms de zone par défaut sont arbitrary pour les secrets arbitraires, api_key pour les données d'identification IAM, username ou password pour les données d'identification de l'utilisateur et key pour clé-valeur.

L'exemple suivant ajoute trois zones de secret-en utilisant le même secret de données d'identification IAM, nommé iam-pour montrer comment les différentes options --field affectent le nom de zone résultant. Vous pouvez afficher les zones ajoutées à un secret en exécutant kubectl get secret et en affichant le bloc data de la sortie.

ibmcloud oc ingress secret field add --cluster example-cluster --name example-iam-secret --namespace openshift-ingress  --field crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa-1a11-111a-aa1a-1111aa1aa111:secret:111a1111-11a1-11aa-a1a1-111aa12345aa --field custom_iam_name=crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa-1a11-111a-aa1a-1111aa1aa111:secret:111a1111-11a1-11aa-a1a1-111aa12345aa --field prefix=crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa-1a11-111a-aa1a-1111aa1aa111:secret:111a1111-11a1-11aa-a1a1-111aa12345aa

Exemples de zones répertoriées dans le bloc data des détails du secret.

data:
  api_key: bmZrUHR1VS1fNVpMOExsTmIxeTdQcXFTSENMc2pTUjRsNTQyTzZkZ2ZQMkk=  # Default field type using the default `api_key` field name
  custom_iam_name: bmZrUHR1VS1fNVpMOExsTmIxeTdQcXFTSENMc2pTUjRsNTQyTzZkZ2ZQMkk=  # Named field type using the specified `custom_iam_name` field name.
  iam_api_key: bmZrUHR1VS1fNVpMOExsTmIxeTdQcXFTSENMc2pTUjRsNTQyTzZkZ2ZQMkk= # Prefixed field type using the `iam` name in Secrets Manager followed by the `api_key` default name.

Mise à jour des zones de secret

Exécutez la commande ingress secret update pour mettre à jour les valeurs d'une zone de secret. Notez que cela ne met pas à jour le CRN. Pour plus d'informations et pour connaître les options de commande, voir la référence de l'interface de ligne de commande.

ibmcloud oc ingress secret update --cluster example-cluster --name example-secret --namespace openshift-ingress

Suppression d'une zone de secret

Vous pouvez supprimer une zone de secret d'un secret non TLS. Pour plus d'informations et pour connaître les options de commande, voir la référence de l'interface de ligne de commande.

ibmcloud oc ingress secret field rm -c example-cluster --name example-secret --namespace openshift-ingress --field-name example-Field

Vous pouvez vérifier que la zone est supprimée en vérifiant le bloc data des détails du secret.

kubectl get secret -n default example-secret -o yaml

Questions fréquentes sur les secrets

Passez en revue les réponses aux questions fréquemment posées sur la gestion des secrets dans votre cluster.

Mes secrets sont-ils automatiquement mis à jour si je ne crée pas et n'enregistre pas une instance Secrets Manager ?: Si vous n'enregistrez pas d'instance Secrets Manager dans votre cluster, vos secrets Ingress par défaut continuent à être mis à jour automatiquement tous les 90 jours et sont appliqués à votre cluster. Toutefois, les secrets que vous avez créés et qui référencent le secret Ingress par défaut ne sont pas automatiquement mis à jour.; Exemple de scénario: Vous disposez d'un certificat Ingress par défaut dans l'espace de nom default. Vous exécutez la commande ibmcloud oc ingress secret create et référencez le CRN du certificat Ingress par défaut pour mettre en miroir le certificat dans l'espace de nom istio-system. Sans instance Secrets Manager, le certificat Ingress par défaut dans l'espace de nom default est automatiquement mis à jour. Toutefois, vous êtes responsable de la mise à jour régulière du certificat dans l'espace de nom istio-system à l'aide des commandes **kubectl** ou d'une autre méthode de rotation.
J'ai créé des secrets qui font référence au certificat Ingress par défaut, mais je n'ai pas créé et enregistré d'instance Secrets Manager. Comment gérer mes secrets?: Si vous n'enregistrez pas d'instance Secrets Manager, Red Hat OpenShift on IBM Cloud met à jour automatiquement uniquement le secret Ingress par défaut. Vous êtes responsable de la gestion des autres secrets à l'aide des commandes kubectl ou d'une autre méthode de rotation. Si vos secrets font référence au certificat Ingress par défaut, supprimez-les à l'aide de ibmcloud ks ingress secret rm.