Gestión de certificados y secretos TLS y no TLS

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

Considera utilizar Secrets Manager para gestionar de forma centralizada y actualizar automáticamente tus secretos.

Gestión de certificados y secretos de TLS con Ingress

Su certificado Ingress TLS se almacena como secreto en Kubernetes. Para gestionar los secretos de TLS en tu clúster, puedes utilizar el conjunto ibmcloud oc ingress secret de comandos.

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

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

Para importar el certificado con el ibmcloud oc ingress secret create comando, debe tener una instancia Secrets Manager predeterminada registrada en su clúster. Si no dispone de una Secrets Manager instancia y sus secretos se escriben directamente en su clúster, estos no tendrán el valor CRN requerido y deberá copiarlos manualmente con el OpenShiftoc complemento comandos.

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

ibmcloud oc ingress secret ls -c CLUSTER

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

IBM proporciona un subdominio Ingress y un certificado TLS predeterminado, almacenado como secreto Kubernetes en su clúster, que puede especificar en su recurso 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 predeterminado TLS para el subdominio de entrada proporcionado por IBM.

Obtenga el nombre del secreto donde se almacena su certificado por defecto TLS. Tenga en cuenta que este es el nombre de secreto que especifica en la sección spec.tls del recurso de Ingress.
```
ibmcloud oc cluster get -c CLUSTER | grep Ingress
```
Salida de ejemplo
```
Ingress Subdomain:      mycluster-<hash>-0000.us-south.containers.appdomain.cloud
Ingress Secret:         mycluster-<hash>-0000
```
Vea los detalles del secreto y anote el valor de CRN. Este es el CRN del certificado TLS. Si no tiene una instancia [Secrets Manager] registrada en su clúster, su secreto no tiene un CRN. Consulte la nota en el paso siguiente para obtener más detalles.
```
ibmcloud oc ingress secret get -c CLUSTER --name SECRET_NAME --namespace openshift-ingress
```
Crea un secreto para el certificado por defecto TLS en cada espacio de nombres donde existan tus recursos o aplicaciones Ingress. Especifique el CRN del certificado TLS con la opción de comando --cert-crn.
```
ibmcloud oc ingress secret create --cluster CLUSTER_NAME_OR_ID --cert-crn CRN --name SECRET_NAME --namespace openshift-ingress
```
Para copiar el secreto con el ibmcloud oc ingress secret create comando, debe tener una instancia Secrets Manager predeterminada registrada en su clúster. Si no dispone de una Secrets Manager instancia y sus secretos se escriben directamente en su clúster, estos no tendrán el valor CRN requerido y deberá copiarlos manualmente con el OpenShiftoc complemento comandos.

Configuración de TLS secrets 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 Kubernetes para almacenar el certificado TLS y, a continuación, importar este secreto a cada espacio de nombres en el que existan sus aplicaciones.

Si almacena certificados personalizados de TLS en Secrets Manager puede importar sus certificados directamente a un secreto de Kubernetes en su clúster.

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

Para importar el certificado con el ibmcloud oc ingress secret create comando, debe tener una instancia Secrets Manager predeterminada registrada en su clúster. Si no dispone de una Secrets Manager instancia y sus secretos se escriben directamente en su clúster, estos no tendrán el valor CRN requerido y deberá copiarlos manualmente con el OpenShiftoc complemento comandos.
```
ibmcloud oc ingress secret create --name SECRET_NAME --cluster CLUSTER_NAME_OR_ID --cert-crn CERTIFICATE_CRN --namespace openshift-ingress
```
Repita el paso anterior para cada espacio de nombres donde existan las apps.

Gestión de secretos no TLS

Para gestionar los secretos no TLS, puede utilizar los comandos ibmcloud oc ingress secret.

Existen 5 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.
Las credenciales personalizadas contienen valores personalizados (cadena).

Aprenda a gestionar de forma centralizada sus secretos no TLS con IBM Cloud Secrets Manager. Con Secrets Manager, puede crear secretos gestionados en Kubernetes, actualizar sus secretos automáticamente, crear grupos de secretos que controlen quién tiene acceso a los secretos de su clúster y mucho más.

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

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

El siguiente comando 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 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

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

kubectl get secret -n default

El siguiente ejemplo muestra el resultado.

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 secreto es un par clave-valor que se almacena en un secreto no TLS. Consulte los siguientes ejemplos 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://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

También puede listar los campos en un secreto con los mandatos ibmcloud oc ingress secret field ls y ibmcloud oc 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ñade un campo secreto a un secreto que no sea TLS ejecutando el comando ibmcloud oc 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 oc ingress secret create. Esta opción no es compatible con los secretos de 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 los 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 IAM nombre de usuario/contraseña clave/valor Credenciales personalizadas

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 clave-valor.

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

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 oc ingress secret update --cluster example-cluster --name example-secret --namespace openshift-ingress

Eliminación de un campo de secreto

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

ibmcloud oc ingress secret field rm -c example-cluster --name example-secret --namespace openshift-ingress --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 oc 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, Red Hat OpenShift on IBM Cloud 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.