Esta página se ha traducido con Cloud Translation API.

Usar autoridades de certificación de clústeres personalizadas

Las autoridades de certificación (CAs) de clústeres emiten y firman certificados para habilitar la autenticación y el cifrado seguros entre los componentes del clúster. De forma predeterminada, en Google Distributed Cloud, la API de clúster crea las CAs de clúster cuando creas un clúster. En este documento se describe cómo puedes usar tus propias autoridades de certificación con Google Distributed Cloud. Si usas ACs de clúster personalizadas, tendrás más control sobre la emisión y la gestión de los certificados de tu clúster. También puedes controlar la confianza, los parámetros del algoritmo de cifrado, la profundidad de los certificados subordinados y su finalidad.

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. Proporciona un par de archivos de certificado y clave de AC para cada una de las siguientes ACs de clúster obligatorias:

AC de etcd: el certificado de la AC de etcd protege la comunicación del servidor de la API de Kubernetes con las réplicas de etcd y la comunicación entre las réplicas de etcd.
AC del clúster: el certificado de la AC 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. Entre los clientes se incluyen kubelet, el gestor de controladores y el programador.
AC de proxy frontal: el certificado de la AC de proxy frontal protege la comunicación con las APIs agregadas.

Puede proporcionar un par de claves y certificados único para cada AC o reutilizar un par de claves y certificados para más de una AC.

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

Requisitos previos

Eres responsable de preparar tus propias CAs raíz de acuerdo con las siguientes reglas:

Las AC personalizadas son AC raíz, cada una de las cuales consta de un archivo de certificado autofirmado y un archivo de clave privada.
Para su certificado, le recomendamos que utilice el formato de reglas de codificación distinguidas (DER). Consulte la recomendación X.690 sobre las reglas de codificación ASN.1. El archivo de certificado debe contener datos codificados en Base64 precedidos por ‑‑‑‑‑BEGIN CERTIFICATE‑‑‑‑‑ y seguidos por ‑‑‑‑END CERTIFICATE‑‑‑‑‑.
En el caso de la clave privada, te recomendamos que utilices el formato Public-Key Cryptography Standards (PKCS) #1. El 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 autoridades de certificación personalizadas no deben caducar antes de cinco años. Recomendamos un periodo 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 del administrador donde 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 que ya se utilice 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 bmctl debe tener acceso de lectura a los archivos.

Usar una CA 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 sus características y ajustes. Para usar la función de CA de clúster personalizada durante la creación del clúster, tienes dos opciones para especificar las CAs de clúster personalizadas en el archivo de configuración del clúster:

Especifica las rutas de los archivos de certificado de CA y de los archivos de clave privada.
Especifica solo las rutas de los archivos de clave privada

Si solo especifica las claves privadas, bmctl buscará los archivos de certificado de 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 .crt. Por ejemplo, si la ruta de la clave privada es /custom-ca/cluster_ca.key, bmctl espera que la ruta del certificado sea /custom-ca/cluster_ca.crt.

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

Ejemplo 1: Especificar las rutas de los certificados y las claves

En el siguiente fragmento de un archivo de configuración de clúster se muestra cómo especificar las rutas a los archivos de certificado y de clave de cada autoridad de certificación del clúster. En este ejemplo, los archivos de clave y certificado de la autoridad certificadora se encuentran en el mismo directorio que los archivos de clave JSON de la cuenta de servicio.

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: Especificar solo las rutas de las claves privadas

En el siguiente fragmento de un archivo de configuración de clúster se muestra cómo especificar solo las rutas a los archivos de claves. En este ejemplo, los archivos de clave privada de la CA se encuentran en el mismo directorio que los archivos de clave JSON de la cuenta de servicio. Los archivos de certificado de 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 del certificado de CA de etcd tiene el nombre etcd_ca.crt.

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: Reutilizar un solo par de archivos de certificado y clave de AC

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

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

Usar una AC personalizada durante la rotación de ACs

Cuando rota las ACs, puede especificar las rutas de los archivos de certificado y clave privada de la AC de su clúster personalizado. Las opciones que tienes son similares a las que se usan para especificar CAs de clúster personalizados durante la creación del clúster. Cuando ejecutas el comando bmctl update credentials certificate-authorities rotate, tienes las siguientes opciones:

Especifica las rutas de los archivos de certificado de CA personalizada y de los archivos de clave privada.
Especifica solo las rutas de los archivos de clave privada de la AC 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 la extensión .crt.
Reutiliza un par de claves de certificado de AC especificando las mismas rutas de certificado y clave para más de una AC de clúster.
Omitir los argumentos de las rutas de CA personalizadas. Si no especificas rutas de AC personalizadas al rotar las ACs, Google Distributed Cloud crea y usa la AC de clúster estándar.

Ejemplo 1: Especificar las rutas de la clave privada y el certificado de CA

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

Haz los cambios siguientes:

CLUSTER_NAME: el nombre del clúster para el que quieres rotar las autoridades certificadoras.
ADMIN_KUBECONFIG: la ruta al archivo kubeconfig del clúster de administrador. En el caso de los clústeres autogestionados, este archivo es el archivo kubeconfig del clúster.
CLUSTER_CA_CERT_PATH: la ruta del archivo de certificado de la CA del clúster.
CLUSTER_CA_KEY_PATH: la ruta del archivo de clave privada de la AC del clúster.
ETCD_CA_CERT_PATH: la ruta del archivo del certificado de CA de etcd.
ETCD_CA_KEY_PATH: la ruta del archivo de clave privada de la CA de etcd.
FRONT_PROXY_CA_CERT_PATH: la ruta del archivo de certificado del proxy frontal.
FRONT_PROXY_CA_KEY_PATH: la ruta del archivo de clave privada del proxy frontal.

Ejemplo 2: Especificar solo las rutas de las claves privadas

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

Haz los cambios siguientes:

CLUSTER_NAME: el nombre del clúster para el que quieres rotar las autoridades certificadoras.
ADMIN_KUBECONFIG: la ruta al archivo kubeconfig del clúster de administrador. En el caso de los clústeres autogestionados, este archivo es el archivo kubeconfig del clúster.
CLUSTER_CA_KEY_PATH: la ruta del archivo de clave privada de la AC del clúster.
ETCD_CA_KEY_PATH: la ruta del archivo de clave privada de la CA de etcd.
FRONT_PROXY_CA_KEY_PATH: la ruta del archivo de clave privada del proxy frontal.

Autoridades de certificación intermedias

Los clústeres de la versión 1.29 admiten el uso de autoridades de certificación intermedias como función de vista previa. Esta función no se encuentra en la misma fase de lanzamiento en todas las versiones de producto compatibles:

1.29: Vista previa
1.28: no disponible
1.16: no disponible

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

CA de etcd
CA de clúster
AC de proxy frontal

Al igual que con las ACs raíz, puedes proporcionar un par de clave y certificado único para cada AC o reutilizar un par de clave y certificado para más de una AC especificando las mismas rutas de archivo en la configuración de la AC.

Cuando usas CAs intermedias, el archivo de certificado de la CA debe contener toda la cadena de certificados, incluidos los certificados de las CAs intermedias y de la CA raíz. Los certificados se muestran en orden inverso a como se firmaron, con el último certificado de CA intermedia en la parte superior y el certificado de CA raíz en la parte inferior.

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

La CA raíz ha firmado 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 de CA intermedia Y final, que se firmó con la CA intermedia X.

Para continuar con este ejemplo, la clave privada asociada al certificado de AC intermedia Y debe enviarse junto con las cadenas de certificados de AC de la misma forma que en una AC personalizada.

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

Para comprobar si el clúster usa la AC intermedia, inspecciona el número de certificados del secreto de la AC 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