Como configurar identidade e segurança

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Nesta página, descrevemos como ativar a autenticação do OpenID Connect (OIDC) em clusters de usuário, como configurar o controle de acesso baseado em papéis (RBAC, na sigla em inglês) e como usar o Logon único (SSO, na sigla em inglês) do Google para autenticação. 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ário com a IU do centro de gerenciamento para ver instruções sobre como criar clusters de usuário. 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 isolated 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.

Como 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. Consulte Fazer o download do arquivo de configuração de login do cluster de usuários para conseguir a configuração de login da IU do centro de gerenciamento do modo particular do Anthos. 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-anthos-config.yaml

Distribua user-cluster-anthos-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-anthos-config.yaml \
  --cluster=USER_CLUSTER_NAME --kubeconfig=./user-cluster-oidc-kubeconfig

Substitua USER_CLUSTER_NAME pelo nome do cluster de usuário, conforme mostrado no Admin Console. --kubeconfig=user-cluster-oidc-kubeconfig é o nome do arquivo de saída do Kubeconfig.

Aviso: a saída Kubeconfig (user-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-oidc-kubeconfig get pods -A

Como autenticar com o SSO do Google

O SSO do Google não está disponível no modo isolado, e esta seção é somente para fins de demonstração e teste. Se você quiser usar o SSO do Google, o cluster e os navegadores precisam ser capazes de entrar em contato com os servidores de SSO do Google. Os servidores de SSO do Google não precisam entrar em contato com os clusters do usuário.

1. Faça login no console do Google Cloud e selecione um projeto válido.
2. Acesse a seção "API e serviços > Tela de consentimento do OAuth".
3. Crie uma nova tela de consentimento do OAuth. Essa informação geralmente é exibida aos usuários.
   1. Defina a Página inicial do aplicativo como o URL Admin.
4. Na seção APIs e serviços > Credenciais:
   1. Clique em Criar credenciais.
   2. Crie um novo ID do cliente OAuth.
   3. Defina o tipo de aplicativo como Aplicativo da Web.
   4. Escolha um nome relevante.
   5. Para as origens do JavaScript, defina https://anthos.example.com, supondo que https://anthos.example.com seja o nome do domínio do centro de gerenciamento.
   6. Para os URIs de redirecionamento autorizados, configure:
      • https://anthos.example.com/_gcp_anthos_oidc_callback
      • http://localhost:9879/callback
5. Copie o ID e a chave secreta do cliente para a configuração do AdminUI.
6. Defina o URL do provedor OIDC como https://accounts.google.com.
7. Defina Username Claim como email e Scopes como openid email.
8. Defina os parâmetros extras como prompt=consent,access_type=offline. Caso contrário, não será possível fazer login com o servidor da API Kubernetes.
9. Adicione a lista inicial de e-mails dos usuários (separados por vírgulas) para receber permissões de administrador da plataforma.
10. Clique em Save.

Audit logging

A auditoria do Kubernetes está ativada para o modo particular do Anthos, fornecendo a abordagem para verificar o acesso administrativo e as ações na plataforma.

No momento, a geração de registros de auditoria não pode ser personalizada para parâmetros como tempo de retenção, taxa de atualização ou tamanho da parte. O nível de auditoria é Metadata, que registra metadados de solicitação (usuário da solicitação, carimbo de data/hora, recurso, verbo), mas não corpo de solicitação ou resposta.

Observação: os registros de auditoria do cluster k8s de administrador e de usuário são exportados.

A geração de registros de auditoria é ativada no modo particular do Anthos por padrão. Consulte Geração de registros e monitoramento para ver as etapas detalhadas sobre como acessar registros de auditoria.

Observação: no momento, esse não é um local seguro para armazenar registros de auditoria. Pessoas com permissões de k8s suficientes (por exemplo, E/S) pode excluir ou adulterar registros de auditoria.