Gestão de acesso

TLDR: Todo acesso — cluster Kubernetes e CODEOWNERS — sai de um único arquivo: config/access.yml. Editar, abrir PR, mergear em main; o CI aplica o resto. Deploy em produção não exige aprovação de ninguém.

Pré-requisitos

  • aws CLI com o profile wehive-shared configurado
  • kubectl, yq e gh
  • estar listado em config/access.yml

Passos

Conseguir acesso

  1. Adicione-se à seção users do config/access.yml, com o seu username do GitHub.
  2. Peça a um owner do projeto para incluir o seu alias em members (acesso ao cluster) ou owners (ter exec e port-forward em produção).
  3. Abra um PR e mergeie — o merge exige aprovação de um CODEOWNER.

Configurar o kubectl

bash make k8s.init

Isso cria o seu contexto (wehive-<alias>), auto-cria o profile AWS necessário em ~/.aws/config, e mostra os contextos disponíveis. O token é gerado por aws eks get-token e expira em 15 minutos — a renovação é automática, você não precisa fazer nada.

bash make k8s.context.change # menu interativo para trocar de contexto

Formato do config/access.yml

```yaml users: seunome: github: seu-username-github

devops: owners: # aprovam PR nos repos listados (CODEOWNERS) - seunome repos: - infrastructure - commons

projects: meuapp: apps: # repos que pertencem ao projeto - meuapp-api - meuapp-web members: # acessam os namespaces do projeto no cluster - seunome owners: # exec e port-forward em production - seunome ```

O que cada seção controla

Seção O que faz
users mapeia alias → username do GitHub; é a fonte de verdade das identidades
devops.owners acesso total ao cluster e aprovação de PR nos devops.repos
devops.repos repos que herdam esse CODEOWNERS
projects.<p>.apps repos que pertencem ao projeto
projects.<p>.members acesso aos namespaces do projeto no cluster
projects.<p>.owners exec e port-forward em production

Acesso ao cluster por perfil

Perfil Namespaces --staging Namespaces --production Namespaces de sistema
member total somente leitura, sem exec nem port-forward nenhum acesso
owner total total, com exec e port-forward nenhum acesso
devops total total total

Túnel de banco em produção (make <app>.db.tunnel.production) exige perfil owner: ele cria um pod proxy, faz port-forward nele e o remove no final — as três operações são exclusivas do owner.

Você só vê no kubectl get namespaces (e no k9s) os namespaces onde tem RoleBinding explícito — não há leitor global de namespace.

Como o CI aplica

mermaid graph TD A["merge de config/access.yml em main"] --> B["gen-access-tfvars.sh<br/>gera access.auto.tfvars.json"] B --> C["terraform apply no stack de kubernetes"] C --> D["aws_iam_role eks-dev-{alias}<br/>+ aws_eks_access_entry"] C --> E["RoleBindings por namespace<br/>conforme member/owner"] A --> G["sync-codeowners.sh<br/>.github/CODEOWNERS"]

O access.yml é a única fonte de verdade: o Terraform não duplica a lista de projetos, ele consome o access.auto.tfvars.json gerado a partir do YAML.

Troubleshooting

Forbidden num namespace que eu deveria acessar

Confira se o seu alias está em members do projeto certo e se o apply do stack de kubernetes rodou depois do merge. Verifique o que a sua identidade pode fazer:

bash kubectl auth can-i get pods -n <projeto>--staging

Nenhum contexto criado por make k8s.init

Você não tem projeto no access.yml, ou o aws CLI não consegue assumir o role. Confirme:

bash aws sts get-caller-identity --profile wehive-shared

Perdi o acesso de repente

A revogação é imediata por construção: se o seu IAM role foi removido do access.yml, o acesso acaba no mesmo apply. Não é bug.

Referências