IBM Cloud Docs
Gestión de certificados y secretos TLS y no TLS

Gestión de certificados y secretos TLS y no TLS

Aprenda a utilizar certificados y secretos en el clúster.

Considere la posibilidad de utilizar Secrets Manager para gestionar de forma centralizada y actualizar automáticamente los secretos.

Gestión de certificados y secretos TLS con Ingress

El certificado TLS de Ingress se almacena como un secreto de Kubernetes. Para gestionar los secretos TLS en el clúster, puede utilizar el conjunto de mandatos ibmcloud ks ingress secret.

Por ejemplo, puede importar un certificado de Secrets Manager a un secreto de Kubernetes en el clúster ejecutando el mandato siguiente.

ibmcloud ks ingress secret create --cluster <cluster_name_or_ID> --cert-crn <crn> --name <secret_name> --namespace default

Para importar el certificado con el mandato ibmcloud ks ingress secret create, debe tener una instancia predeterminada de Secrets Manager registrada en el clúster. Si no tiene una instancia de Secrets Manager y, en su lugar, los secretos se escriben directamente en el clúster, los secretos no tienen el valor de CRN necesario y debe copiarlos manualmente con mandatos kubectl.

Para ver todos los secretos de Ingress para certificados TLS en el clúster, ejecute el mandato siguiente.

ibmcloud ks ingress secret ls -c <cluster>

Configuración de secretos TLS para el subdominio de Ingress proporcionado por IBM

IBM proporciona un subdominio de Ingress y un certificado TLS predeterminado, almacenado como un secreto de Kubernetes en el clúster, que puede especificar en el recurso de Ingress. Los certificados TLS proporcionados por IBM están firmados por LetsEncrypt y están gestionados por completo por IBM.

El comodín del subdominio de Ingress proporcionado por IBM, *.<cluster_name>.<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud, está registrado de forma predeterminada para el clúster. El certificado TLS proporcionado por IBM es un certificado comodín, y se puede utilizar para el subdominio comodín.

Siga los pasos para utilizar el certificado TLS predeterminado para el subdominio de Ingress proporcionado por IBM.

  1. Obtenga el nombre del secreto donde se almacena el certificado TLS predeterminado. Tenga en cuenta que este es el nombre de secreto que especifica en la sección spec.tls del recurso de Ingress.

    ibmcloud ks cluster get -c <cluster> | grep Ingress

    Salida de ejemplo

    Ingress Subdomain:      mycluster-<hash>-0000.us-south.containers.appdomain.cloud
Ingress Secret:         mycluster-<hash>-0000

  2. Vea los detalles del secreto y anote el valor de CRN. Es el CRN del certificado TLS. Si no tiene una instancia predeterminada de [Secrets Manager] registrada en el clúster, el secreto no tiene un CRN. Consulte la nota en el paso siguiente para obtener más detalles.

    ibmcloud ks ingress secret get -c <cluster> --name <secret_name> --namespace default

  3. Cree un secreto para el certificado TLS predeterminado en cada espacio de nombres donde existan los recursos o apps de Ingress. Especifique el CRN de certificado TLS con la opción de mandato --cert-crn.

    De forma alternativa, puede establecer el secreto como defaultCertificate en el mapa de configuración ibm-ingress-deploy-config.

    ibmcloud ks ingress secret create --cluster <cluster_name_or_ID> --cert-crn <CRN> --name <secret_name> --namespace default

    Para copiar el secreto con el mandato ibmcloud ks ingress secret create, debe tener una instancia predeterminada de Secrets Manager registrada en el clúster. Si no tiene una instancia de Secrets Manager y, en su lugar, los secretos se escriben directamente en el clúster, los secretos no tienen el valor de CRN necesario y debe copiarlos manualmente con mandatos kubectl.

Configuración de secretos TLS para subdominios personalizados

Si define un subdominio personalizado en el recurso de Ingress, puede utilizar su propio certificado TLS para gestionar la terminación de TLS. Debe crear un secreto de Kubernetes para almacenar el certificado TLS y, a continuación, importar este secreto en cada espacio de nombres donde existan las apps.

Al almacenar certificados TLS personalizados en Secrets Manager, puede importar los certificados directamente en un secreto de Kubernetes en el clúster.

  1. Cree o importe un secreto para el certificado TLS en el espacio de nombres donde existe el recurso de Ingress. Por ejemplo, puede importar un secreto de Secrets Manager en el clúster ejecutando el mandato siguiente. Especifique el CRN del certificado TLS con la opción de mandato --cert-crn.

    Para importar el certificado con el mandato ibmcloud ks ingress secret create, debe tener una instancia predeterminada de Secrets Manager registrada en el clúster. Si no tiene una instancia de Secrets Manager y, en su lugar, los secretos se escriben directamente en el clúster, los secretos no tienen el valor de CRN necesario y debe copiarlos manualmente con mandatos kubectl.

    ibmcloud ks ingress secret create --name <secret_name> --cluster <cluster_name_or_ID> --cert-crn <certificate_crn> --namespace default

  2. Repita el paso anterior para cada espacio de nombres donde existan las apps.

Gestión de secretos no TLS

Para gestionar secretos no TLS, puede utilizar los mandatos ibmcloud ks ingress secret.

Hay 4 tipos de secretos no TLS:

  • Los secretos arbitrarios contienen un valor de serie.
  • Las credenciales de IAM contienen una clave de API de IAM.
  • Secretos de nombre de usuario y contraseña contienen un nombre de usuario y una contraseña como dos valores separados.
  • Los valores de clave contienen valores JSON.

Descubra cómo puede gestionar de forma centralizada sus secretos no TLS con IBM Cloud Secrets Manager. Con Secrets Manager, puede crear secretos Kubernetes gestionados, actualizar los secretos automáticamente, crear grupos de secretos que controlen quién tiene acceso a los secretos del clúster, etc.

Creación de un secreto no TLS en el clúster

Cree un secreto no TLS especificando la opción --type Opaque en el mandato ibmcloud ks ingress secret create. Con el tipo Opaque, puede incluir varios valores de CRN que no sean de certificado. Si no se especifica la opción --type, TLS se aplica de forma predeterminada. Para obtener más información y opciones de mandato adicionales, consulte la Referencia de CLI.

El siguiente mandato de ejemplo crea un secreto no TLS con el tipo Opaque especificado. Los secretos no TLS requieren al menos un campo secreto. Tenga en cuenta que la forma en que especifica la opción --field varía en función del tipo de secreto que cree.

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

Para verificar que se ha creado el secreto, liste todos los secretos del espacio de nombres.

kubectl get secret -n default

El ejemplo siguiente muestra la salida.

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

Gestión de campos secretos no TLS

Un campo de secreto es un par de clave-valor que se almacena en un secreto no TLS. Consulte los ejemplos siguientes para ver, añadir, actualizar o eliminar campos secretos no TLS.

Visualización de valores de campo

Puede ver los valores de los campos de un secreto obteniendo los detalles del secreto.

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

La salida de ejemplo siguiente muestra los campos de secreto y sus valores en la sección 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

También puede listar los campos en un secreto con los mandatos ibmcloud ks ingress secret field ls y ibmcloud ks ingress secret get, pero las salidas sólo incluyen el nombre de campo y no el valor asociado a él.

Adición de un campo de secreto

Añada un campo de secreto a un secreto no TLS ejecutando el mandato ibmcloud ks ingress secret field add con la opción --field. También puede utilizar esta opción para añadir campos al crear un secreto con el mandato ibmcloud ks ingress secret create. Esta opción no está soportada para secretos TLS.

Hay tres formas de especificar la opción --field. El que elija depende del tipo de secreto y de cómo desee nombrar el campo en el secreto.

Opciones para añadir campos a secretos no TLS
Opción Formato Descripción Tipos de secretos soportados
Valor predeterminado --field <crn> El nombre del campo añadido es el nombre de campo predeterminado para el tipo de secreto del CRN especificado. Todos los tipos de secreto no TLS
con nombre --field <name>=<crn> Utilice esta opción para especificar un nombre para el campo añadido. El nombre del campo añadido es el valor especificado para <name>. -Arbitrario
-credenciales de IAM
Con prefijo --field prefix=<crn> El nombre del campo añadido es el nombre de campo predeterminado para el tipo de secreto especificado por el CRN especificado, con el prefijo del nombre del secreto especificado por el <crn> y un carácter de subrayado. -Credenciales de IAM
-username/password
-key/value

Los nombres de campo predeterminados son arbitrary para secretos arbitrarios, api_key para credenciales de IAM, username o password para credenciales de usuario y key para valor de clave.

El ejemplo siguiente añade tres campos secretos-utilizando el mismo secreto de credenciales de IAM, denominado iam-para mostrar cómo las distintas opciones de --field afectan al nombre de campo resultante. Puede ver los campos añadidos a un secreto ejecutando kubectl get secret y visualizando el bloque data de la salida.

ibmcloud ks ingress secret field add --cluster example-cluster --name example-iam-secret --namespace default  --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

Campos de ejemplo listados en el bloque data de los detalles del secreto.

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.

Actualización de campos de secreto

Ejecute el mandato ingress secret update para actualizar los valores de un campo secreto. Tenga en cuenta que esto no actualiza el CRN. Para obtener más información y opciones de mandato, consulte la Referencia de CLI.

ibmcloud ks ingress secret update --cluster example-cluster --name example-secret --namespace default

Eliminación de un campo de secreto

Puede eliminar un campo de secreto de un secreto no TLS. Para obtener más información y opciones de mandato, consulte la Referencia de CLI.

ibmcloud ks ingress secret field rm -c example-cluster --name example-secret --namespace default --field-name example-Field

Puede verificar que el campo se ha eliminado comprobando el bloque data de los detalles del secreto.

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

Preguntas más frecuentes sobre secretos

Revise las respuestas a las preguntas más frecuentes sobre la gestión de secretos en el clúster.

¿Se actualizan automáticamente mis secretos si no creo y registro una instancia de Secrets Manager ?
Si no registra una instancia de Secrets Manager en el clúster, los secretos de Ingress predeterminados continúan actualizándose automáticamente cada 90 días y se aplican al clúster. Sin embargo, los secretos que ha creado que hacen referencia al secreto de Ingress predeterminado no se actualizan automáticamente.
Escenario de ejemplo: tiene un certificado de Ingress predeterminado en el espacio de nombres de default. Ejecute el mandato ibmcloud ks ingress secret create y haga referencia al CRN del certificado de Ingress predeterminado para duplicar el certificado en el espacio de nombres istio-system. Sin una instancia de Secrets Manager, el certificado de Ingress predeterminado del espacio de nombres default se actualiza automáticamente. Sin embargo, es responsable de actualizar regularmente el certificado en el espacio de nombres istio-system con los mandatos **kubectl** u otro método de rotación.
He creado secretos que hacen referencia al certificado de Ingress predeterminado, pero no he creado y registrado una instancia de Secrets Manager. ¿Cómo puedo gestionar mis secretos?
Si no registra una instancia de Secrets Manager, IBM Cloud Kubernetes Service sólo actualiza automáticamente el secreto de Ingress predeterminado. Usted es responsable de gestionar cualquier otro secreto utilizando mandatos kubectl u otro método de rotación. Si los secretos hacen referencia al certificado de Ingress predeterminado, elimínelos utilizando ibmcloud ks ingress secret rm.