Usa autoridades certificadoras de clúster personalizadas

Las autoridades certificadoras (AC) del clúster emiten y firman certificados para habilitar la autenticación y la encriptación seguras entre los componentes del clúster. De forma predeterminada, en Google Distributed Cloud, la API de Cluster crea las AC del clúster cuando creas un clúster nuevo. En este documento, se describe cómo puedes usar tus propias autoridades de certificación con Google Distributed Cloud. El uso de CAs de clúster personalizadas te brinda más control sobre la emisión y administración de los certificados de tu clúster. También puedes controlar la confianza, los parámetros del algoritmo de encriptación, la profundidad de los certificados subordinados y su propósito.

Para usar ACs personalizadas, debes proporcionar ACs raíz, que constan de un archivo de certificado de AC y su archivo de clave privada correspondiente. Proporcionas un par de archivos de clave y certificado de CA para cada una de las siguientes ACs de clúster requeridas:

• CA de etcd: El certificado de la CA de etcd protege la comunicación del servidor de la API de Kubernetes a las réplicas de etcd y también la comunicación entre réplicas de etcd.

• CA del clúster: El certificado de la CA del clúster protege la comunicación entre el servidor de la API de Kubernetes y todos los clientes internos de la API de Kubernetes. Los clientes incluyen kubelet, el administrador de controladores y el programador.

• CA de proxy principal: El certificado de la CA de proxy principal protege la comunicación con las APIs agregadas.

Puedes proporcionar un par de claves de certificado único para cada AC o puedes reutilizar un par de claves de certificado para más de una de las ACs.

Los pares de clave y certificado se aplican durante la creación del clúster (solo el método bmctl) y la rotación de la AC. La función de CA de clúster personalizada funciona con todos los tipos de clústeres: administrador, usuario, híbrido y autónomo.

Nota: Cuando creas un clúster de usuario con bmctl, por lo general, quitas la sección de credenciales del archivo de configuración del clúster. Para especificar ACs de clúster personalizadas cuando creas un clúster de usuario, especifica solo las rutas de acceso de la clave privada y el certificado de la AC del clúster personalizado en la sección de credenciales.

Requisitos previos

Eres responsable de preparar tus propias AC raíz según las siguientes reglas:

• Las ACs personalizadas son ACs raíz, cada una de las cuales consta de un archivo de certificado autofirmado y un archivo de clave privada.

• Para tu certificado, te recomendamos que uses el formato de reglas de codificación distinguidas (DER) (consulta la recomendación X.690 para las reglas de codificación de ASN.1). Tu archivo de certificado debe contener datos codificados en base64 precedidos por ‑‑‑‑‑BEGIN CERTIFICATE‑‑‑‑‑ y seguidos por ‑‑‑‑END CERTIFICATE‑‑‑‑‑.

• Para la clave privada, te recomendamos que uses el formato de los Estándares de criptografía de clave pública (PKCS) #1. Tu archivo de claves debe contener datos codificados en Base64 precedidos por ‑‑‑‑BEGIN RSA PRIVATE KEY‑‑‑‑ y seguidos por ‑‑‑‑END RSA PRIVATE KEY‑‑‑‑.

• Para minimizar las posibles interrupciones del clúster, las ACs personalizadas no deben vencer antes de los cinco años. Te recomendamos un período de vencimiento más largo, como de 10 a 30 años.

• Asegúrate de que los archivos de certificado y clave estén en la estación de trabajo de administrador en la que ejecutas los comandos bmctl.

• El usuario que ejecuta los comandos de bmctl debe tener acceso al directorio en el que almacenas los archivos. Te recomendamos que coloques los archivos en un directorio existente que se use para certificados y claves. Por ejemplo, puedes almacenar los archivos en ~/baremetal/bmctl-workspace/.sa-keys junto con las claves de tu cuenta de servicio.

• El usuario que ejecuta los comandos de bmctl debe tener acceso de lectura a los archivos.

Usa una AC personalizada durante la creación del clúster

Cuando creas un clúster con bmctl, primero actualizas el archivo de configuración del clúster para describir las funciones y la configuración del clúster. Para usar la función de AC de clúster personalizado durante la creación del clúster, tienes dos opciones para especificar las ACs de clúster personalizado en el archivo de configuración del clúster:

• Especifica las rutas de acceso de los archivos de certificados de la AC y de los archivos de claves privadas.
• Especifica solo las rutas de acceso a los archivos de claves privadas.

Cuando especificas solo las claves privadas, bmctl busca los archivos de certificados de la CA correspondientes en el mismo directorio. Los archivos de certificado deben tener el mismo nombre que los archivos de clave privada correspondientes y la extensión de archivo .crt. Por ejemplo, si la ruta de acceso de la clave privada es /custom-ca/cluster_ca.key, bmctl espera que la ruta de acceso del certificado sea /custom-ca/cluster_ca.crt.

En ambos casos, las rutas de acceso se especifican en la sección de credenciales del archivo de configuración, como se muestra en los siguientes ejemplos.

Ejemplo 1: Especifica las rutas de acceso al certificado y la clave

En el siguiente extracto de un archivo de configuración de clúster, se muestra cómo especificar las rutas de acceso a los archivos de certificados y claves para cada AC del clúster. En este ejemplo, los archivos de claves y certificados de la CA se encuentran en el mismo directorio que los archivos de claves JSON de la cuenta de servicio.

Nota: En el caso de un clúster de usuario, debes quitar las rutas de acceso de la cuenta de servicio y la clave SSH de la sección de credenciales.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCACertPath: bmctl-workspace/.sa-keys/cluster_ca_cert.pem
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCACertPath: bmctl-workspace/.sa-keys/etcd_ca_cert.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCACertPath: bmctl-workspace/.sa-keys/front_proxy_ca_cert.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Ejemplo 2: Especifica solo las rutas de acceso a la clave privada

En el siguiente extracto de un archivo de configuración de clúster, se muestra cómo especificar solo las rutas de acceso a los archivos de claves. En este ejemplo, los archivos de claves privadas de la CA se encuentran en el mismo directorio que los archivos de claves JSON de la cuenta de servicio. Los archivos de certificado de la CA correspondientes también deben estar en el directorio /.sa-keys. Los archivos de certificado tienen el mismo nombre que los archivos de clave, pero con la extensión .crt. Por lo tanto, el archivo de certificado de la CA de etcd tiene el nombre etcd_ca.crt.

Nota: En el caso de un clúster de usuario, debes quitar las rutas de acceso de la cuenta de servicio y la clave SSH de la sección de credenciales.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Ejemplo 3: Vuelve a usar un solo par de archivos de claves y certificados de AC

En el siguiente extracto de un archivo de configuración de clúster, se muestra cómo especificar solo las rutas de acceso a los archivos de claves. En este ejemplo, se usa un solo par de claves de certificado para todas las AC del clúster. Los archivos de certificado de CA y clave privada se encuentran en el directorio /custom-ca. Según la convención de nomenclatura, el nombre del archivo del certificado de la CA es custom_ca.crt.

Nota: En el caso de un clúster de usuario, debes quitar las rutas de acceso de la cuenta de servicio y la clave SSH de la sección de credenciales.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: /custom-ca/custom_ca.key
etcdCAPrivateKeyPath: /custom-ca/custom_ca.key
frontProxyCAPrivateKeyPath: /custom-ca/custom_ca.key
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Usa una AC personalizada durante la rotación de AC

Cuando rotas las ACs, puedes especificar las rutas de acceso para los archivos de claves privadas y el certificado de AC del clúster personalizado. Las opciones que tienes son similares a las opciones para especificar ACs de clústeres personalizados durante la creación de clústeres. Cuando ejecutas el comando bmctl update credentials certificate-authorities rotate, tienes las siguientes opciones:

• Especifica las rutas de acceso de los archivos de certificados de ACs personalizadas y de los archivos de claves privadas.
• Especifica solo las rutas de acceso de los archivos de claves privadas de la CA personalizada. El archivo de certificado de CA correspondiente debe estar en el mismo directorio, tener el mismo nombre que el archivo de clave y tener una extensión de archivo .crt.
• Especifica las mismas rutas de acceso de claves y certificados para más de una AC del clúster para reutilizar un par de claves y certificados de AC.
• Omite los argumentos para las rutas de acceso de la CA personalizada. Si no especificas rutas de acceso de ACs personalizadas cuando rotas las ACs, Google Distributed Cloud crea y usa la AC del clúster estándar.

Ejemplo 1: Especifica las rutas de acceso del certificado de CA y la clave privada

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-cert-path=CLUSTER_CA_CERT_PATH \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-cert-path=ETCD_CA_CERT_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-cert-path=FRONT_PROXY_CA_CERT_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

Reemplaza lo siguiente:

• CLUSTER_NAME: Es el nombre del clúster en el que deseas rotar las CAs.
• ADMIN_KUBECONFIG es la ruta al archivo kubeconfig del clúster de administrador. Para los clústeres autoadministrados, este archivo es el archivo kubeconfig del clúster.
• CLUSTER_CA_CERT_PATH: Es la ruta de acceso al archivo del certificado de la CA del clúster.
• CLUSTER_CA_KEY_PATH: Es la ruta de acceso al archivo de claves privadas de la AC del clúster.
• ETCD_CA_CERT_PATH: Es la ruta de acceso al archivo del certificado de AC de etcd.
• ETCD_CA_KEY_PATH: Es la ruta de acceso al archivo de claves privadas de la AC de etcd.
• FRONT_PROXY_CA_CERT_PATH: Es la ruta de acceso al archivo del certificado del proxy frontal.
• FRONT_PROXY_CA_KEY_PATH: Es la ruta de acceso al archivo de claves privadas del proxy frontal.

Ejemplo 2: Especifica solo las rutas de acceso a la clave privada

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

Reemplaza lo siguiente:

• CLUSTER_NAME: Es el nombre del clúster en el que deseas rotar las CAs.
• ADMIN_KUBECONFIG es la ruta al archivo kubeconfig del clúster de administrador. Para los clústeres autoadministrados, este archivo es el archivo kubeconfig del clúster.
• CLUSTER_CA_KEY_PATH: Es la ruta de acceso al archivo de claves privadas de la AC del clúster.
• ETCD_CA_KEY_PATH: Es la ruta de acceso al archivo de claves privadas de la AC de etcd.
• FRONT_PROXY_CA_KEY_PATH: Es la ruta de acceso al archivo de claves privadas del proxy frontal.

AC intermedias

Vista previa

Este producto o función está sujeto a las "Condiciones de la Oferta de la Fase Previa a la DG" en la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Los productos y las funciones de la fase previa a la DG están disponibles "sin modificaciones" y pueden estar sujetos a asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Los clústeres de la versión 1.29 admiten el uso de ACs intermedias como una función de versión preliminar. Esta función no se encuentra en la misma etapa de lanzamiento para todas las versiones de productos compatibles:

• 1.29: Vista previa
• 1.28: No disponible
• 1.16: No disponible

Al igual que con el requisito de la AC raíz para las ACs personalizadas, para usar ACs intermedias, debes preparar tres conjuntos de AC. Cada CA consta de un archivo de certificado de CA y su archivo de clave privada correspondiente. Proporcionas un par de archivos de clave y certificado de CA para cada una de las siguientes ACs de clúster requeridas:

• CA de etcd
• AC del clúster
• CA de proxy principal

Al igual que con las ACs raíz, puedes proporcionar un par de claves de certificado único para cada AC o puedes reutilizar un par de claves de certificado para más de una de las ACs si especificas las mismas rutas de acceso de archivos en la configuración de la AC.

Cuando usas ACs intermedias, el archivo de certificado de AC debe contener toda la cadena de certificados, que incluye los certificados de las ACs intermedias hasta la AC raíz. Los certificados se enumeran en orden inverso a la forma en que se firmaron, con el último certificado de CA intermedio en la parte superior y el certificado de CA raíz en la parte inferior.

En el siguiente ejemplo (comenzando con la CA raíz en la parte inferior), el orden indica lo siguiente:

• La CA raíz firmó el certificado de la CA intermedia A
• La CA intermedia A firmó el certificado de la CA intermedia B.
• La cadena continúa hasta el certificado final de la CA intermedia Y, que fue firmado por la CA intermedia X.

-----BEGIN CERTIFICATE-----
<Intermediate-Y CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Intermediate-X CA CERT CONTENT>
-----END CERTIFICATE-----
...
-----BEGIN CERTIFICATE-----
<Intermediate-B CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Intermediate-A CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<ROOT CA CERT CONTENT>
-----END CERTIFICATE----- 

Para continuar con este ejemplo, la clave privada asociada con el certificado de AC Intermedia-Y se debe pasar junto con las cadenas de certificados de AC de la misma manera que en una AC personalizada.

-----BEGIN RSA PRIVATE KEY-----
<Intermediate-Y PRIVATE KEY CONTENT>
-----END RSA PRIVATE KEY-----

Para verificar si el clúster usa la CA intermedia, inspecciona el recuento de certificados en el secreto de la CA del clúster:

kubectl get secret CLUSTER_NAME-ca \
    --kubeconfig ADMIN_KUBECONFIG
    -n cluster-CLUSTER_NAME \
    -o jsonpath='{.data.tls\.crt}' | base64 --decode | grep "BEGIN CERTIFICATE" | wc -l