Autenticar en el servidor de la API de Kubernetes


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:

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:

  1. 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
    
    .
  2. 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.
  3. 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.

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

  2. 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 nombres prod a una cuenta de servicio llamada cicd en el espacio de nombres cicd-ns:

    kubectl create rolebinding cicd-secret-viewer \
        --namespace=prod \
        --clusterrole=view \
        --serviceaccount=cicd-ns:cicd
    
  3. 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.

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

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

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

.
  1. 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
    
  2. 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 de ci-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.

  3. 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
    
  4. 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
    
  5. 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:

  1. 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
    
  2. 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 de ci-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.

  3. 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
    
  4. 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 de clusterCaCertificate de tu clúster:

    gcloud container clusters describe CLUSTER_NAME \
        --location=CONTROL_PLANE_LOCATION \
        --format="value(masterAuth.clusterCaCertificate)"
    
  5. 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 para endpoint 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ámetro cluster del archivo kubeconfig.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.

  6. Despliega kubeconfig.yaml y gsa-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
    
  7. 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