Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

Conceda ao controlador do balanceador de carga do Modo Automático do EKS acesso a um segredo específico

Neste tutorial, você concede ao controlador do balanceador de carga do Modo Automático do Amazon EKS acesso de leitura a um Secret Kubernetes específico. Isso desbloqueia a autenticação OIDC em um ALB Ingress. Você usa um Role com escopo de namespace e RoleBinding direcionado ao grupo eks:managed.

Este tutorial leva aproximadamente 15 minutos para ser concluído. Os objetos RBAC do Kubernetes que você cria não incorrem em cobranças da AWS.

O controlador do balanceador de carga do Modo Automático do Amazon EKS oferece suporte à autenticação OIDC em objetos ALB Ingress. Ele usa a anotação alb.ingress.kubernetes.io/auth-type: oidc para habilitar essa autenticação. Para resolver a configuração do OIDC, o controlador lê um Secret Kubernetes nomeado na anotação alb.ingress.kubernetes.io/auth-idp-oidc. Atualmente, sua política de acesso gerenciado não concede get em objetos Secret; portanto, o reconciliador falha com uma mensagem semelhante a:

Failed build model due to ingress: <ns>/<name>:
  secrets "<secret>" is forbidden:
  User "arn:aws:sts::<acct>:assumed-role/AWSServiceRoleForAmazonEKS/<session>"
  cannot get resource "secrets" in API group "" in the namespace "<ns>"

Usando o mecanismo descrito em Conceda RBAC do Kubernetes adicional aos controladores gerenciados do Modo Automático do EKS, você pode conceder ao controlador gerenciado get exatamente o Secret OIDC de que ele precisa.

Pré-requisitos

Antes de começar, você deve ter o seguinte:

Etapa 1: identifique o segredo a ser adicionado à lista de permissões

A configuração de OIDC em um ALB Ingress é semelhante ao seguinte. Registre o nome do Secret e o namespace de Ingress; os objetos RBAC devem residir no mesmo namespace do Secret.

annotations:
  alb.ingress.kubernetes.io/auth-type: oidc
  alb.ingress.kubernetes.io/auth-idp-oidc: >
    {
      "issuer": "...",
      "authorizationEndpoint": "...",
      "tokenEndpoint": "...",
      "userInfoEndpoint": "...",
      "secretName": "oidc"
    }

O restante deste exemplo usa o namespace monitoring e o nome Secret oidc.

Etapa 2: aplique um Role e um RoleBinding com escopo de namespace

Esse formulário concede exatamente get no Secret nomeado em exatamente um namespace. Salve o seguinte como eks-managed-oidc-secret-reader.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: eks-managed-oidc-secret-reader
  namespace: monitoring
rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["oidc"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: eks-managed-oidc-secret-reader
  namespace: monitoring
subjects:
- kind: Group
  name: eks:managed
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: eks-managed-oidc-secret-reader
  apiGroup: rbac.authorization.k8s.io

Aplicar:

kubectl apply -f eks-managed-oidc-secret-reader.yaml

Para adicionar mais objetos Secret à lista de permissões posteriormente, anexe seus nomes à lista Role’s `resourceNames e reaplique.

Etapa 3: confirme a recuperação do Ingress

O controlador do balanceador de carga reconcilia o Ingress na próxima passagem (normalmente em alguns minutos). Quando a concessão está funcionando, o erro secrets "oidc" is forbidden anterior deixa de aparecer no Ingress e o balanceador de carga progride. Se o erro persistir, verifique novamente o Role’s `namespace, resourceNames e o assunto RoleBinding.

Como remover a concessão

Se você parar de usar o OIDC no Ingress, remova a concessão:

kubectl delete rolebinding eks-managed-oidc-secret-reader -n monitoring
kubectl delete role        eks-managed-oidc-secret-reader -n monitoring

Recursos relacionados