Usar autoridades certificadoras de clúster personalizadas

Las autoridades certificadoras (AC) del clúster emiten y firman certificados para habilitar la autenticación y encriptación seguras entre los componentes del clúster. De forma predeterminada, en GKE en Bare Metal, la API de clúster crea las CA del clúster cuando creas un clúster nuevo. En este documento, se describe cómo puedes usar tus propias autoridades certificadoras con GKE en Bare Metal. El uso de AC de clústeres personalizados te brinda más control sobre la emisión y la 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 AC personalizadas, debes proporcionar AC raíz, que constan de un archivo de certificado de la AC y el archivo de claves privadas correspondiente. Proporciona un certificado de la AC y un par de archivos de claves para cada una de las siguientes AC requeridas del clúster:

  • CA de etcd: El certificado para el certificado de la AC 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 para 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. Entre los clientes, se incluyen kubelet, el administrador del controlador y el programador.

  • CA del proxy frontal: El certificado para la AC del proxy frontal protege la comunicación con 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 AC.

Debes aplicar los pares de clave de certificado durante la creación del clúster (solo para el método bmctl) y la rotación de la AC. La función de AC del clúster personalizado funciona con todos los tipos de clústeres: administrador, usuario, híbrido e independiente.

Requisitos previos

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

  • Las AC personalizadas son AC raíz, cada una de las cuales consiste en un archivo de certificado autofirmado y un archivo de claves privadas.

  • Las AC intermedias y subordinadas no son compatibles.

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

  • Para la clave privada, te recomendamos que uses el formato 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 de ‑‑‑‑END RSA PRIVATE KEY‑‑‑‑.

  • Para minimizar la posible interrupción del clúster, las AC personalizadas no deben vencer antes de cinco años. Te recomendamos un período de vencimiento más largo, como de 10 a 30 años.

  • Asegúrate de que el certificado y los archivos de claves se encuentren en la estación de trabajo de administrador en la que ejecutas los comandos de bmctl.

  • El usuario que ejecuta los comandos de bmctl debe tener acceso al directorio en el que se almacenan los archivos. Te recomendamos colocar 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 comandos 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 debes actualizar el archivo de configuración del clúster para describir sus funciones y configuración. Para usar la función de AC del clúster personalizado durante la creación del clúster, tienes dos opciones para especificar las AC del clúster personalizadas en el archivo de configuración del clúster:

  • Especifica las rutas de acceso para los archivos de certificado de la AC y los archivos de claves privadas
  • Especifica las rutas de acceso solo para los archivos de claves privadas

Cuando especificas solo las claves privadas, bmctl busca los archivos de certificado de la AC correspondientes en el mismo directorio. Los archivos de certificado deben tener el mismo nombre que los archivos de claves privadas correspondientes y la extensión de archivo .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 cualquier caso, las rutas se especifican en la sección de credenciales del archivo de configuración como se muestra en los siguientes ejemplos.

Ejemplo 1: Especifica rutas de acceso de claves y certificados

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 claves y certificados para cada AC del clúster. En este ejemplo, el certificado de la AC y los archivos de claves están en el mismo directorio que los archivos de claves 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: Especifica solo rutas de acceso de claves privadas

En el siguiente extracto de un archivo de configuración de clúster, se muestra cómo especificar las rutas de acceso solo a los archivos de claves. En este ejemplo, los archivos de claves privadas de la AC se encuentran en el mismo directorio que los archivos de claves JSON de la cuenta de servicio. Los archivos de certificados de la AC correspondientes también deben estar en el directorio /.sa-keys. Los archivos de certificados tienen el mismo nombre de archivo que los archivos de claves, pero con una extensión .crt. Por lo tanto, el archivo de certificado de la AC 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: Vuelve a usar un solo par de archivos de claves y certificado de la AC

En el siguiente extracto de un archivo de configuración de clúster, se muestra cómo especificar las rutas de acceso solo a los archivos de claves. En este ejemplo, se usa un solo par de certificados y claves para todas las AC del clúster. El certificado de la AC y los archivos de claves privadas se encuentran en el directorio /custom-ca. Siguiendo la convención de nombres, el nombre de 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
...

Cómo usar una AC personalizada durante la rotación de AC

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

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

Ejemplo 1: Especifica rutas de acceso de clave privada y certificado de la AC

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 para el que deseas rotar las AC.
  • 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 del archivo de certificado de la AC del clúster.
  • CLUSTER_CA_KEY_PATH: Es la ruta de acceso del archivo de claves privadas de la CA del clúster.
  • ETCD_CA_CERT_PATH: Es la ruta de acceso del archivo de certificado de la AC de etcd.
  • ETCD_CA_KEY_PATH: Es la ruta de acceso del archivo de claves privadas de la CA de etcd.
  • FRONT_PROXY_CA_CERT_PATH: Es la ruta de acceso del archivo de certificado del proxy frontal.
  • FRONT_PROXY_CA_KEY_PATH: Es la ruta de acceso del archivo de claves privadas del proxy frontal.

Ejemplo 2: Especifica solo rutas de acceso de 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

Reemplaza lo siguiente:

  • CLUSTER_NAME: Es el nombre del clúster para el que deseas rotar las AC.
  • 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 del archivo de claves privadas de la CA del clúster.
  • ETCD_CA_KEY_PATH: Es la ruta de acceso del archivo de claves privadas de la CA de etcd.
  • FRONT_PROXY_CA_KEY_PATH: Es la ruta de acceso del archivo de claves privadas del proxy frontal.