Como podemos limitar uma conta de serviço para poder criar, listar, excluir etc. objetos que possuem um rótulo específico em um determinado namespace?
Projetamos uma hierarquia de serviços (que são mapeados para namespaces do Kubernetes) e componentes (que são representados por um personarótulo em vários objetos) e os integramos ao Vault de forma que os segredos aos quais você tem acesso sejam específicos de um serviço. par de componentes. Isso ajuda a segregar as coisas. Por exemplo, imagine uma equipe que gerencia várias implantações e apenas algumas delas lidam com dados PII. Podemos usar esse rótulo para conceder acesso seletivo a esses segredos.
# only approximatively k8s objects
---
kind: Deployment
metadata:
name: backend
namespace: banana
labels:
persona: backend
spec: ...
# pods in this deployment have access to banana§backend secrets via a vault sidecar
---
kind: Deployment
metadata:
name: frontend
labels:
persona: frontend
spec: ...
# pods in this deployment have access to banana§frontend secrets via a vault sidecar
No entanto, isso significa que não queremos apenas criar uma conta de serviço que possa gerenciartodospods nesse namespace — se o segredo dessa conta de serviço vazar, um invasor poderá usá-lo para iniciar um pod com uma imagem maliciosa e acesso a PII.
Então, eu gostaria de ter algo como: (observe que meu conhecimento sobre contas de serviço, funções e vinculações de funções é extremamente limitado)
# even more approximatively so k8s objects
kind: Role
metadata:
name: deploy-frontend
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
selector:
labels:
persona: frontend
# even if compromised, this service account cannot access banana§backend secrets
Parece k8spoderapoiar algo vagamente parecido com isto, por exemplo, fornecendo uma lista de nomes de recursos específicos (#), mas que isso não é algo que o k8s suporta no momento? Ou eu estou esquecendo de alguma coisa?
Nossa única alternativa é configurar uma conta de serviço em todo o cluster com amplo acesso a tudo e, em seguida, criar um serviço da Web que faça sua própria rotina personalizada de autenticação e autorização antes do token ser usado? Se sim, como podemos limitar ao máximo o alcance desta “conta de Deus”?
Responder1
O Kubernetes não tem como restringir olistaverbo por objeto. Se você puder listar uma coleção, poderá ler todos os objetos dessa coleção.
Talvez um dia isso mude, mas agora é assim que o Kubernetes funciona em termos de coleções e acesso de leitura. Isso inclui acesso de leitura aos segredos…
No entanto, se você quiser restringirescrevepara objetos, você pode fazer isso. Você pode limitar a capacidade de gravar em objetos nomeados específicos usando:
- um webhook de admissão de validação externa
- uma (beta) ValidatingAdmissionPolicy
- um webhook de autorização
ou usando regras RBAC cuidadosamente elaboradas.
Algo que pode ajudá-lo a gerenciar o acesso é ocontrolador de namespaces hierárquicos, permitindo que uma equipe gerencie umdefinirde namespaces, cada um com suas próprias restrições. Se o seu cluster suportar ValidatingAdmissionPolicies, você poderá usá-los para aumentar o acesso delegado e as restrições ao acesso de gravação (embora esse seja um tópico bastante complicado).
Se você deseja ter uma ServiceAccount que possa fazer coisas, mas delegar o controle dessas coisas, você pode criar uma ServiceAccount em cada namespace de destino com um RoleBinding e permitir que a ServiceAccount geral represente as ServiceAccounts específicas. Novamente, isso é algo bastante complexo de abordar, mas é possível.