Soluciona problemas de identidad y autorización

En este documento, se proporciona orientación para solucionar problemas de identidad y autorización.

Mantén gcloud anthos auth actualizado

Puedes evitar muchos problemas habituales si verificas que los componentes de la instalación de gcloud anthos auth estén actualizados.

Hay dos partes que deben verificarse, puesto que el comando gcloud anthos auth tiene lógica en el componente principal de gcloud y un componente anthos-auth empaquetado por separado.

Actualiza gcloud con este comando:

gcloud components update

Actualiza anthos-auth con este comando:

gcloud components install anthos-auth

La configuración del proveedor no es válida

Si la configuración de tu proveedor de identidad no es válida, verás una pantalla de error del proveedor de identidad después de hacer clic en ACCEDER. Sigue las instrucciones específicas del proveedor para configurar correctamente el proveedor o el clúster.

Los permisos no son válidos

Si completas el flujo de autenticación, pero aún no ves los detalles del clúster, asegúrate de haber otorgado los permisos de RBAC correctos a la cuenta que usaste con OIDC. Ten en cuenta que esta cuenta podría ser diferente de la que usas para acceder a la consola de Google Cloud.

Falta el token de actualización

El siguiente problema se produce cuando el servidor de autorización solicita el consentimiento, pero no se proporcionó el parámetro de autenticación necesario.

Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct

Para resolver este problema, agrega prompt=consent al campo authentication.oidc.extraParams en el archivo de configuración del clúster. Luego, vuelve a generar el archivo de autenticación del cliente.

Token de actualización vencido

Este problema se produce cuando venció el token de actualización en el archivo kubeconfig:

Unable to connect to the server: Get {DISCOVERY_ENDPOINT}: x509:
    certificate signed by unknown authority

Para resolver este problema, vuelve a ejecutar el comando login.

gkectl create-login-config no puede obtener clientconfig

Este problema se genera cuando el archivo kubeconfig que se pasa a gkectl create-login-config no es para un clúster de usuarios o el recurso personalizado de ClientConfig no surgió durante la creación del clúster.

Error getting clientconfig using KUBECONFIG

A fin de resolver este problema, asegúrate de tener el archivo kubeconfig correcto para tu clúster de usuario. Luego, verifica si el objeto ClientConfig está en el clúster:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG  get clientconfig default -n kube-public

gkectl create-login-config falla debido a un nombre de clúster duplicado

Este problema se produce si intentas escribir datos de configuración de acceso que contienen un nombre de clúster que ya existe en el archivo de destino. Cada archivo de configuración de acceso debe contener nombres de clúster únicos.

error merging with file MERGE_FILE because MERGE_FILE contains a
  cluster with the same name as the one read from KUBECONFIG. Please write to
  a new output file

A fin de solucionar este problema, usa la marca --output para especificar un archivo de destino nuevo.

Si no proporcionas --output, los datos de configuración de acceso se escriben en un archivo llamado kubectl-anthos-config.yaml en el directorio actual.

gcloud anthos auth login falla con proxyconnect tcp

Este problema se produce cuando hay un error en las opciones de configuración de las variables de entorno https_proxy o HTTPS_PROXY. Si se especifica https:// en las variables de entorno, las bibliotecas cliente HTTP de GoLang pueden fallar si el proxy está configurado para controlar conexiones HTTPS mediante otros protocolos, como SOCK5.

Posible mensaje de error:

proxyconnect tcp: tls: first record does not look like a TLS handshake

A fin de resolver este problema, modifica las variables de entorno https_proxy y HTTPS_PROXY para omitir https:// prefix. En Windows, modifica las variables de entorno del sistema. Por ejemplo, cambia el valor de la variable de entorno https_proxy de https://webproxy.example.com:8000 a webproxy.example.com:8000.

El acceso al clúster falla cuando se usa kubeconfig que genera gcloud anthos auth login

Este problema se produce cuando el servidor de la API de Kubernetes no puede autorizar al usuario. Esto puede ocurrir si faltan los RBAC adecuados o son incorrectos, o hay un error en la configuración de OIDC para el clúster.

Unauthorized

Para solucionar este problema, sigue estos pasos:

  1. En el archivo kubeconfig que generó gcloud anthos auth login, copia el valor de id-token.

    kind: Config
…
users:
— name: …
  user:
    auth-provider:
      config:
        id-token: xxxxyyyy

  2. Instala jwt-cli y ejecuta lo siguiente:

    jwt ID_TOKEN

  3. Verifica la configuración de OIDC.

    El authentication.oidc en el archivo de configuración del clúster de usuario tiene los campos group y username, que se usan para establecer las marcas --oidc-group-claim y --oidc-username-claim en la API de Kubernetes. Cuando se presenta el servidor de API con el token, reenvía el token al servicio de identidad de Anthos, que muestra el group-claim y los username-claim extraídos al servidor AIP. El servidor de la API usa la respuesta para verificar que el grupo o usuario correspondiente tenga los permisos correctos.

    Verifica que las reclamaciones establecidas para group y user en la sección authentication.oidc del archivo de configuración del clúster estén presentes en el token de ID.

  4. Verifica los RBAC que se aplicaron.

    Verifica que haya un RBAC con los permisos correctos para el usuario que especifica username-claim o uno de los grupos enumerados en group-claim del paso anterior. El nombre del usuario o grupo en el RBAC debe tener el prefijo usernameprefix o groupprefix que se especificó en el archivo de configuración del clúster de usuario.

    Ten en cuenta que si usernameprefix está en blanco y username es un valor distinto de email, el prefijo se establece de forma predeterminada en issuerurl#. Para inhabilitar los prefijos de nombre de usuario, establece usernameprefix en -.

    Para obtener más información sobre los prefijos de usuario y grupo, consulta Autentica con OIDC

    Ten en cuenta que el servidor de la API de Kubernetes trata una barra inversa como un carácter de escape. Por lo tanto, si el nombre del usuario o grupo contiene \\, el servidor de la API lo lee como una sola \ cuando analiza el token de ID. Es por eso que la vinculación de función de RBAC aplicado a este usuario o grupo debe contener solo una barra inversa o es posible que se produzca un error Unauthorized.

    Archivo de configuración de clúster:

    oidc:
  ...
  username: "unique_name"
  usernameprefix: "-"
  group: "group"
  groupprefix: "oidc:"

    Token de ID:

    {
  ...
  "email": "cluster-developer@example.com",
  "unique_name": "EXAMPLE\\cluster-developer",
  "group": [
    "Domain Users",
    "EXAMPLE\\developers"
  ],
...
}

    Las siguientes vinculaciones de RBAC otorgan a este grupo y usuario la función de clúster pod-reader. Observa la barra diagonal simple en el campo del nombre en lugar de una barra doble:

    Grupo de ClusterRoleBinding:

    apiVersion:
kind: ClusterRoleBinding
metadata:
  name: example-binding
subjects:
— kind: Group
  name: "oidc:EXAMPLE\developers"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

    Usuario de ClusterRoleBinding:

    apiVersion:
kind: ClusterRoleBinding
metadata:
  name: example-binding
subjects:
— kind: User
  name: "EXAMPLE\cluster-developer"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

  5. Revisa los registros del servidor de la API de Kubernetes.

    Si el complemento de OIDC configurado en el servidor de la API de Kubernetes no se inicia de forma correcta, el servidor de la API muestra un error Unauthorized cuando se presenta con el token de ID. Para ver si hubo algún problema con el complemento OIDC en el servidor de la API, ejecuta lo siguiente:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG logs statefulset/kube-apiserver -n USER_CLUSTER_NAME