Configurar a autenticação do OIDC em clusters de usuários

Esta página é destinada a administradores da plataforma.

Nesta página, descrevemos como ativar a autenticação do OpenID Connect (OIDC) em clusters de usuários e configurar o controle de acesso baseado em papéis (RBAC, na sigla em inglês). Para saber mais sobre a autenticação com o OIDC, consulte Gerenciamento de identidade com o OIDC em clusters do Anthos em bare metal.

Ativar a autenticação OIDC em clusters de usuário

A autenticação OIDC pode ser ativada durante a criação do cluster de usuário ou em um cluster de usuário atual. A condição prévia para configurar a autenticação do OIDC é que os perfis de identidade a serem aplicados ao cluster já existam. Consulte Como criar perfis de identidade.

Definir perfis de identidade durante a criação do cluster

Consulte Criar clusters de usuários para ver instruções sobre como criar clusters de usuários com o Console do Anthos Management Center. Para criar um cluster de usuário, acesse a página Configuração de cluster e selecione os perfis de identidade na lista suspensa Configurações do AIS. Esses perfis de identidade serão aplicados ao cluster de usuário.

Definir perfis de identidade em um cluster de usuário atual

1. Acesse a página Identidade e acesso.

   

2. Clique em Aplicar perfis aos clusters.

   

3. Selecione os perfis de identidade a serem aplicados na lista suspensa Perfis.

4. Selecione os clusters que receberão os perfis de identidade na lista suspensa Clusters.

Visualizar perfis de identidade aplicados ao cluster de usuário

Os perfis de identidade aplicados ao cluster de usuário podem ser visualizados na página Identidade e acesso.

Selecione a guia Cluster, encontre o cluster de usuário a ser visualizado e clique em Ver detalhes de configuração para esse cluster.

Fazer o download do arquivo de configuração de login do cluster de usuário

Na página deslizante Ver detalhes de configuração, clique em Fazer o download da configuração de login.

Especificar a configuração do OIDC do arquivo

Crie um arquivo contendo o seguinte: Salve este arquivo como user-cluster-oidc-config.yaml:

spec:
  authentication:
  - name: CONFIGURATION_NAME
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      # The URI to redirect users going through the OAuth flow using cloud
      # console.
      # This is a required parameter not supported by Anthos running in
      # disconnected mode, so a dummy value is required.
      cloudConsoleRedirectURI: http://cloud.console.not.enabled
      extraParams: EXTRA_PARAMS
      issuerURI: ISSUER_URI
      # The redirect URL that kubectl uses for authorization.
      kubectlRedirectURI: http://localhost:9879/callback
      scopes: SCOPES
      userClaim: USER_CLAIM
      groupsClaim: GROUPS_CLAIM
      certificateAuthorityData: CERT_AUTHORITY_DATA

Substitua:

• CONFIGURATION_NAME: o nome da configuração do OIDC a ser criada.
• CLIENT_ID: o ID do aplicativo cliente que faz solicitações de autenticação para o provedor OpenID.
• CLIENT_SECRET: secret para o aplicativo cliente.
• EXTRA_PARAMS: parâmetros de chave-valor extras (separados por vírgulas) para enviar ao provedor OpenID.
• ISSUER_URI: URL para onde as solicitações de autorização são enviadas para o OpenID.
• SCOPES: escopos adicionais (separados por vírgulas) para enviar ao provedor OpenID.
• USER_CLAIM: a declaração do JWT a ser usada como nome de usuário. É possível escolher outras declarações, como e-mail ou nome, dependendo do provedor OpenID. No entanto, as declarações diferentes de e-mail são prefixadas com o URL do emissor para evitar conflitos de nomenclatura.
• GROUPS_CLAIM: nome da declaração no token de ID do OIDC que contém as informações do grupo do usuário.
• CERT_AUTHORITY_DATA: um certificado opcional codificado em PEM codificado em base64 para o provedor OIDC. Remova-o se não for necessário. Para criar a string, codifique o certificado, incluindo cabeçalhos, em base64. Inclua a string resultante em certificateAuthorityData como uma única linha.

Depois de editar o arquivo com a configuração desejada, execute o seguinte comando:

kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG clientconfig default -n kube-public \
  --type=merge --patch "$(cat OIDC_CONFIG)"

Substitua:

• USER_CLUSTER_KUBECONFIG: caminho para o arquivo Kubeconfig do cluster de usuário.
• OIDC_CONFIG: caminho para o arquivo de configuração que você criou.

Configurar o RBAC no cluster de usuário

Nesta seção, você verá um exemplo de como configurar o RBAC para conceder acesso a namespaces individuais. Para informações mais detalhadas, consulte a documentação do RBAC do Kubernetes.

Suponha que há dois namespaces, workload-a e workload-b. O objetivo é tornar os recursos no namespace workload-a legíveis e graváveis pelo usuário [e-mail] e workload-b legíveis pelo usuário [e-mail]. [e-mail] não pode acessar workload-b e [e-mail] não pode acessar workload-a.

Crie os namespaces no cluster de usuário:

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-a
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-b

Para limitar o acesso a cada namespace, é necessário definir a permissão de cada namespace. No Kubernetes, isso pode ser feito criando um papel.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-a
  name: a-full-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]
EOF

Os verbs definidos para foo-full-access definem todas as ações que este papel tem permissão para executar no namespace.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-b
  name: b-read-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list"]
EOF

Para b-read-access, os verbos definidos permitem apenas que o papel consulte recursos.

Para que os usuários recebam permissões, é preciso criar RoleBindings. RoleBindings pode incluir usuários individuais e grupos. Este exemplo mostra usuários individuais.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: a-full-access-users
  namespace: workload-a
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: [e-mail] # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: a-full-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

O RoleBinding acima (a-full-access-users) concede ao usuário [e-mail] as permissões definidas no papel a-full-access. Isso significa que o usuário [e-mail] pode ler e gravar recursos no namespace workload-a.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: b-read-access-users
  namespace: workload-b
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: [e-mail] # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: b-read-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

Este RoleBinding (b-read-access-users) concede ao usuário [e-mail] as permissões definidas no papel b-read-access. Como resultado, o usuário [e-mail] só pode ler recursos no namespace workload-b.

Observação: na produção, recomendamos que você vincule papéis a grupos em vez de usuários individuais. Consulte o provedor do OIDC para saber como expor grupos.

Fazer login com o provedor OIDC

Como administrador do cluster do usuário, consiga o arquivo de configuração de login que será usado por todos os usuários do cluster de usuário para fazer login. Veja a configuração de login no Anthos Management Center em Fazer o download do arquivo de configuração de login do cluster de usuário. Também é possível criar o arquivo de configuração de login executando:

actl auth create-login-config --kubeconfig=USER_CLUSTER_KUBECONFIG \
  --output=USER_CLUSTER_NAME-actl-auth-login-config.yaml

Distribua USER_CLUSTER_NAME-actl-auth-login-config.yaml aos usuários do cluster de usuário.

Faça a autenticação com o provedor OIDC e siga as instruções na linha de comando:

actl auth login --login-config=USER_CLUSTER_NAME-actl-auth-login-config.yaml \
  --cluster=USER_CLUSTER_NAME --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig \
  --preferred-auth="CONFIGURATION_NAME"

Substitua USER_CLUSTER_NAME pelo nome do cluster de usuário, conforme mostrado no Admin Console. --kubeconfig=USER_CLUSTER_NAME-cluster-oidc-kubeconfig é o nome do arquivo de saída do Kubeconfig. Substitua CONFIGURATION_NAME pelo nome do perfil de identidade para autenticação. Abra USER_CLUSTER_NAME-actl-auth-login-config.yaml para ver os nomes de perfil.

Aviso: a saída Kubeconfig (USER_CLUSTER_NAME-cluster-oidc-kubeconfig acima) contém credenciais de usuário e não deve ser compartilhada.

Use o novo Kubeconfig com kubectl da seguinte maneira:

kubectl --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig get pods -A

A seguir

• Saiba mais sobre como visualizar registros de auditoria.