Gestion des certificats et des secrets TLS et non TLS

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

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

Gestion des certificats et des secrets TLS avec Ingress

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

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 ibmcloud oc ingress secret create commande, vous devez disposer d'une instance par Secrets Manager défaut enregistrée dans votre cluster. Si vous ne disposez pas d'une instance Secrets Manager et que vos secrets sont directement enregistrés dans votre cluster, ceux-ci ne possèdent pas la valeur CRN requise et vous devez les copier manuellement à l'aide des commandes du oc 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

Mise en place des secrets TLS pour le sous-domaine Ingress fourni par IBM

IBM fournit un sous-domaine Ingress et un certificat TLS par défaut, stocké 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 par défaut TLS pour le sous-domaine d'entrée fourni par IBM.

  1. Obtenir le nom du secret dans lequel est stocké votre certificat TLS par défaut. 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

  2. Affichez les détails du secret et notez la valeur CRN. Il s'agit du CRN du certificat TLS. Si vous n'avez pas d'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

  3. Créez un secret pour le certificat TLS par défaut dans chaque espace de noms 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 ibmcloud oc ingress secret create commande, vous devez disposer d'une instance par Secrets Manager défaut enregistrée dans votre cluster. Si vous ne disposez pas d'une instance Secrets Manager et que vos secrets sont directement enregistrés dans votre cluster, ceux-ci ne possèdent pas la valeur CRN requise et vous devez les copier manuellement à l'aide des commandes du oc 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 noms où vos applications existent.

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

  1. Créez ou importez un secret pour le certificat TLS dans l'espace de noms où se trouve votre ressource Ingress. Par exemple, vous pouvez importer un secret de 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 ibmcloud oc ingress secret create commande, vous devez disposer d'une instance par Secrets Manager défaut enregistrée dans votre cluster. Si vous ne disposez pas d'une instance Secrets Manager et que vos secrets sont directement enregistrés dans votre cluster, ceux-ci ne possèdent pas la valeur CRN requise et vous devez les copier manuellement à l'aide des commandes du oc plug-in OpenShift.

    ibmcloud oc ingress secret create --name SECRET_NAME --cluster CLUSTER_NAME_OR_ID --cert-crn CERTIFICATE_CRN --namespace openshift-ingress

  2. 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 les secrets non TLS, vous pouvez utiliser les commandes ibmcloud oc ingress secret.

Il existe 5 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.
  • Les informations d'identification personnalisées contiennent des valeurs (chaînes) personnalisées.

Découvrez comment vous pouvez 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 dans votre cluster, et plus encore.

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 dans la commande Avec le type Opaque, vous pouvez inclure plusieurs valeurs CRN non-certificat. Si l'option --type n'est pas spécifiée, le style 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 nécessitent au moins un champ secret. 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 le résultat.

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 champs secrets non TLS

Un champ secret est une paire clé-valeur qui est stockée dans un secret non TLS. Consultez les exemples suivants pour afficher, ajouter, mettre à jour ou supprimer les champs secrets 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://url.com
    razee.io/source-url: https://url.com
  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 un champ secret à un secret qui n'est pas de type 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 d' 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 pour l'ajout de champs aux 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 secrets 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
  • Identifiants 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.
  • Informations d'identification IAM
  • nom d'utilisateur/mot de passe
  • clé/valeur
  • Informations d'identification personnalisées

Les noms de champ par défaut sont arbitrary pour les secrets arbitraires, api_key pour les informations d'identification IAM, username ou password pour les informations d'identification utilisateur, et key pour les clés-valeurs.

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 un champ 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.