En esta página se explica cómo autenticarte de forma segura en el servidor de la API de Kubernetes desde clústeres de GKE. Puedes proteger tu clúster asegurándote de que solo los usuarios y las aplicaciones autorizados accedan a tus recursos de Kubernetes. Descubrirás los métodos de autenticación disponibles, el método de autenticación recomendado y cómo autenticar usuarios, aplicaciones y sistemas antiguos.
Para obtener información sobre cómo autenticar cargas de trabajo de Kubernetes en lasGoogle Cloud APIs, consulta Workload Identity Federation for GKE.
Esta página está dirigida a especialistas en seguridad y operadores que deben autenticarse de forma segura en el servidor de la API de Kubernetes desde clústeres de GKE. En esta página se proporciona información esencial sobre los métodos de autenticación disponibles y cómo implementarlos. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud
Antes de leer esta página, asegúrese de que conoce los siguientes conceptos:
- Descripción general de la autenticación en Google Cloud
- Descripción general de la gestión de identidades y accesos y del control de acceso basado en roles (RBAC) en GKE
- Descripción general de los métodos de autenticación de Kubernetes
Antes de empezar
Antes de empezar, asegúrate de haber realizado las siguientes tareas:
- Habilita la API de Google Kubernetes Engine. Habilitar la API de Google Kubernetes Engine
- Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando
gcloud components update
.
Autenticar usuarios
GKE gestiona la autenticación de usuarios finales a través de la CLI de Google Cloud. La CLI de gcloud autentica a los usuarios en Google Cloud, configura Kubernetes, obtiene un token de acceso de OAuth para el clúster y mantiene el token de acceso actualizado.
Todos los clústeres de GKE están configurados para aceptar identidades de usuario y de cuenta de servicio. Para ello, validan las credenciales presentadas por Google Cloud
kubectl
y recuperan la dirección de correo asociada a la identidad de usuario o de cuenta de servicio. Por lo tanto, las credenciales de esas cuentas deben incluir el userinfo.email
ámbito de OAuth para autenticarse correctamente.
Cuando usas gcloud
para configurar el kubeconfig
de tu entornogcloud
para un clúster nuevo o ya creado, gcloud
proporciona a kubectl
las mismas credenciales que usa gcloud
. Por ejemplo, si usas gcloud auth login
, tus credenciales personales se proporcionan a kubectl
, incluido el ámbito userinfo.email
. De esta forma, el clúster de GKE puede autenticar al cliente kubectl
.
También puede configurar kubectl
para que use las credenciales de una cuenta de servicioGoogle Cloud mientras se ejecuta en una instancia de Compute Engine. Sin embargo, de forma predeterminada, el ámbito userinfo.email
no se incluye en las credenciales creadas por las instancias de Compute Engine. Por lo tanto, debes añadir este permiso explícitamente, por ejemplo, usando la marca --scopes
cuando se cree la instancia de Compute Engine.
Puedes autorizar acciones en tu clúster mediante Gestión de Identidades y Accesos (IAM) o el control de acceso basado en roles (RBAC) de Kubernetes.
Autenticarse con OAuth
Para autenticarte en tu clúster mediante el método OAuth, haz lo siguiente:
Inicia sesión en gcloud CLI con tus credenciales. Se abrirá un navegador web para completar el proceso de autenticación en Google Cloud:
.gcloud auth login
Obtén las credenciales de Kubernetes de un clúster específico:
gcloud container clusters get-credentials CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATION
Haz los cambios siguientes:
CLUSTER_NAME
: el nombre del clúster.CONTROL_PLANE_LOCATION
: la ubicación de Compute Engine del plano de control de tu clúster. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.
Verifica que te has autenticado:
kubectl cluster-info
Una vez que se hayan autenticado los usuarios o las Google Cloud cuentas de servicio, también deben autorizarse para realizar cualquier acción en un clúster de GKE. Para obtener más información sobre cómo configurar la autorización, consulta el artículo sobre el control de acceso basado en roles.
Autenticar aplicaciones
También puedes autenticarte en el servidor de la API desde una aplicación en un pod sin interacción del usuario, como desde una secuencia de comandos en tu canalización de CI/CD. La forma de conseguirlo depende del entorno en el que se ejecute tu aplicación.
Aplicación en el mismo clúster
Si tu aplicación se ejecuta en el mismo clúster de GKE, usa una cuenta de servicio de Kubernetes para autenticarte.
Crea una cuenta de servicio de Kubernetes y adjúntala a tu pod. Si tu pod ya tiene una cuenta de servicio de Kubernetes o quieres usar la cuenta de servicio predeterminada del espacio de nombres, sáltate este paso.
Usa el control de acceso basado en roles (RBAC) de Kubernetes para conceder a la cuenta de servicio de Kubernetes los permisos que necesita tu aplicación.
En el siguiente ejemplo se conceden permisos
view
a los recursos del espacio de nombresprod
a una cuenta de servicio llamadacicd
en el espacio de nombrescicd-ns
:kubectl create rolebinding cicd-secret-viewer \ --namespace=prod \ --clusterrole=view \ --serviceaccount=cicd-ns:cicd
En el tiempo de ejecución, cuando tu aplicación envía una solicitud a la API de Kubernetes, el servidor de la API autentica las credenciales de la cuenta de servicio.
Aplicaciones en Google Cloud
Si tu aplicación se ejecuta en Google Cloud pero fuera del clúster de destino (por ejemplo, una VM de Compute Engine u otro clúster de GKE), debes autenticarte en el servidor de la API con las credenciales de la cuenta de servicio de IAM disponibles en el entorno.
Asigna una cuenta de servicio de gestión de identidades y accesos a tu entorno. Si tu aplicación se ejecuta en una VM de Compute Engine, asigna una cuenta de servicio de IAM a la instancia. Si tu aplicación se ejecuta en otro clúster de GKE, usa Workload Identity Federation for GKE para configurar tu pod de forma que se ejecute como una cuenta de servicio de IAM.
En los ejemplos que se muestran a continuación, se usa
ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
como cuenta de servicio de gestión de identidades y accesos.Concede a la cuenta de servicio de IAM acceso al clúster.
En el siguiente ejemplo se asigna el rol de gestión de identidades y accesos
roles/container.developer
, que proporciona acceso a los objetos de la API de Kubernetes en los clústeres:gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/container.developer
También puedes usar RBAC para conceder acceso a la cuenta de servicio de IAM al clúster. Ejecuta el comando
kubectl create rolebinding
desde Aplicaciones del mismo clúster y usa--user=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
en lugar de la marca--service-account
.Obtén las credenciales del clúster:
gcloud container clusters get-credentials CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATION
Tu aplicación se autentica automáticamente mediante la cuenta de servicio de IAM definida en el entorno.
Aplicaciones en otros entornos
Si tu aplicación se autentica desde un entorno externo aGoogle Cloud, no podrá acceder a las credenciales de la cuenta de servicio de gestión de identidades y accesos. Para obtener las credenciales del clúster, puedes crear una cuenta de servicio de IAM, descargar su clave y usarla en tiempo de ejecución desde tu servicio para obtener las credenciales del clúster con la CLI de gcloud.
.Crea una cuenta de servicio de IAM para tu aplicación. Si ya tienes una cuenta de servicio de IAM, sáltate este paso.
El siguiente comando crea una cuenta de servicio de gestión de identidades y accesos llamada
ci-cd-pipeline
:gcloud iam service-accounts create ci-cd-pipeline
Concede acceso a tu clúster a la cuenta de servicio de gestión de identidades y accesos.
El siguiente comando concede el rol de
roles/container.developer
IAM a la cuenta de servicio deci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
IAM:gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/container.developer
También puedes usar el control de acceso basado en roles para conceder acceso a la cuenta de servicio de gestión de identidades y accesos al clúster. Ejecuta el comando
kubectl create rolebinding
desde Aplicaciones del mismo clúster y usa--user=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
en lugar de la marca--service-account
.Crea y descarga una clave para tu cuenta de servicio de IAM. Haz que esté disponible para tu aplicación en tiempo de ejecución:
gcloud iam service-accounts keys create gsa-key.json \ --iam-account=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
En el tiempo de ejecución, en el entorno en el que se ejecuta tu aplicación, autentícate en la CLI de gcloud mediante la clave de tu cuenta de servicio de IAM:
gcloud auth activate-service-account ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \ --key-file=gsa-key.json
Usa la CLI de gcloud para obtener las credenciales del clúster:
gcloud config set project PROJECT_ID gcloud container clusters get-credentials CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATION
Entornos sin gcloud
Se recomienda usar la CLI de gcloud para obtener las credenciales del clúster, ya que este método es resistente a eventos del clúster, como la rotación de IP del plano de control o la rotación de credenciales. Sin embargo, si no puedes instalar la CLI de gcloud en tu entorno, puedes crear un archivo kubeconfig estático para autenticarte en el clúster:
Crea una cuenta de servicio de IAM para tu aplicación. Si ya tienes una cuenta de servicio de IAM, sáltate este paso.
El siguiente comando crea una cuenta de servicio de gestión de identidades y accesos llamada
ci-cd-pipeline
:gcloud iam service-accounts create ci-cd-pipeline
Concede acceso a tu clúster a la cuenta de servicio de gestión de identidades y accesos.
El siguiente comando concede el rol de
roles/container.developer
IAM a la cuenta de servicio deci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
IAM:gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/container.developer
También puedes crear un rol de gestión de identidades y accesos personalizado para tener un control detallado sobre los permisos que concedas.
Crea y descarga una clave para tu cuenta de servicio de IAM.
En el siguiente ejemplo, el archivo de claves se llama
gsa-key.json
:gcloud iam service-accounts keys create gsa-key.json \ --iam-account=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
Si usas el endpoint basado en DNS para acceder al plano de control, obtén el valor de
endpoint
de tu clúster:gcloud container clusters describe CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATION \ --format="value(endpoint)"
Si usas el endpoint basado en IP para acceder al plano de control, obtén el valor de
endpoint
del comando anterior y el valor declusterCaCertificate
de tu clúster:gcloud container clusters describe CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATION \ --format="value(masterAuth.clusterCaCertificate)"
Crea un archivo
kubeconfig.yaml
. Utiliza el siguiente formato si usas el endpoint basado en DNS para acceder al plano de control:apiVersion: v1 kind: Config clusters: - name: CLUSTER_NAME cluster: server: https://endpoint users: - name: ci-cd-pipeline-gsa user: exec: apiVersion: client.authentication.k8s.io/v1beta1 args: - --use_application_default_credentials command: gke-gcloud-auth-plugin installHint: Install gke-gcloud-auth-plugin for kubectl by following https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin provideClusterInfo: true contexts: - context: cluster: CLUSTER_NAME user: ci-cd-pipeline-gsa name: CLUSTER_NAME-ci-cd current-context: CLUSTER_NAME-ci-cd
Haz los cambios siguientes:
CLUSTER_NAME
: el nombre de tu clúster.endpoint
: el valor que has obtenido paraendpoint
en el paso anterior.
Si usas endpoints basados en IP para acceder al plano de control, añade el valor que has obtenido para
clusterCaCertificate
en el paso anterior al parámetrocluster
del archivokubeconfig.yaml
:apiVersion: v1 kind: Config clusters: - name: CLUSTER_NAME cluster: server: https://endpoint certificate-authority-data: masterAuth.clusterCaCertificate users: ...
No es necesario decodificar el certificado codificado en Base64.
Despliega
kubeconfig.yaml
ygsa-key.json
junto con tu aplicación en tu entorno. En el tiempo de ejecución, en el entorno en el que se ejecuta tu aplicación, define estas variables de entorno:export KUBECONFIG=path/to/kubeconfig.yaml export GOOGLE_APPLICATION_CREDENTIALS=path/to/gsa-key.json
Ahora tu aplicación puede enviar solicitudes a la API de Kubernetes y se autenticará como la cuenta de servicio de IAM.
Actualizar los métodos de autenticación antiguos
Antes de la integración de OAuth con GKE, el certificado X.509 preaprovisionado o una contraseña estática eran los únicos métodos de autenticación disponibles, pero ya no se recomiendan y deben inhabilitarse. Estos métodos presentan una superficie de ataque más amplia para la vulneración de clústeres y están inhabilitados de forma predeterminada en los clústeres que ejecutan la versión 1.12 de GKE y versiones posteriores. Si utilizas métodos de autenticación antiguos, te recomendamos que los desactives.
Si se habilita, un usuario con el permiso container.clusters.getCredentials
puede obtener el certificado de cliente y la contraseña estática. Los roles roles/container.admin
, roles/owner
y roles/editor
tienen este permiso, así que úsalos con prudencia. Consulta más información sobre los roles de gestión de identidades y accesos en GKE.
Inhabilitar la autenticación con una contraseña estática
Una contraseña estática es una combinación de nombre de usuario y contraseña que valida el servidor de la API. En GKE, este método de autenticación se denomina autenticación básica.
Para actualizar un clúster y eliminar la contraseña estática, sigue estos pasos:
gcloud container clusters update CLUSTER_NAME \
--location=CONTROL_PLANE_LOCATION \
--no-enable-basic-auth
Inhabilitar la autenticación con un certificado de cliente
Con la autenticación mediante certificado, un cliente presenta un certificado que el servidor de la API verifica con la autoridad de certificación especificada. En GKE, la autoridad de certificación (CA) raíz del clúster firma los certificados de cliente.
La autenticación mediante certificado de cliente tiene implicaciones en la autorización del servidor de la API de Kubernetes. Si la autorización de control de acceso basado en atributos (ABAC) está habilitada en el clúster, de forma predeterminada, los certificados de cliente pueden autenticarse y realizar cualquier acción en el servidor de la API. Por otro lado, si el control de acceso basado en roles (RBAC) está habilitado, los certificados de cliente deben tener una autorización específica para los recursos de Kubernetes.
Para crear un clúster sin generar un certificado de cliente, usa la marca --no-issue-client-certificate
:
gcloud container clusters create CLUSTER_NAME \
--location=CONTROL_PLANE_LOCATION
--no-issue-client-certificate
Por el momento, no se puede quitar un certificado de cliente de un clúster. Para dejar de usar la autenticación mediante certificados de cliente en un clúster, asegúrate de que el clúster tenga habilitado el control de acceso basado en roles y de que el certificado de cliente no tenga ninguna autorización en el clúster.
que se usa para operar el clúster y no se puede inhabilitar.Siguientes pasos
- Consulta información sobre la Google Cloud autenticación.
- Consulta información sobre el control de acceso en GKE.
- Consulta información sobre las cuentas de servicio de Google.
- Consulta información sobre Workload Identity Federation para GKE.
- Consulta información sobre cómo reforzar la seguridad de tu clúster.