Como gerenciar usuários do Linux com Kubernetes?
Quero proteger meus clusters com SecurityContext.RunAsUser. A questão é simples: qual usuário devo usar?
Eu sei que o usuário com o UID 1001 (por exemplo) dentro de um contêiner é o usuário com o UID 1001 no host. Portanto, devo criar um usuário com UID 1001 chamado pod_userem todos os meus hosts e forçar todos os pods a usar esse usuário? Ou devo verificar se não há nenhum usuário com este UID em todos os meus hosts? Não encontrei um guia de práticas recomendadas sobre isso.
Tenho o mesmo tipo de pergunta sobre o Dockerfile: devo declarar um usuário no Dockerfile com um UID específico e reutilizá-lo SecurityContext.RunAsUser? Algumas imagens oficiais estão sendo executadas com um usuário específico codificado no Dockerfile e outras são executadas como ninguém. Achei esta postagem interessante, mas não há uma resposta clara: Kubernetes: gerenciamento de usuários do Linux .
Respostas
Minha recomendação ideal aqui seria:
- Seu Dockerfile
RUN adduserpara criar um usuário não root e alternarUSERpara esse usuário após fazer toda a instalação do software - Você não precisa especificar explicitamente um ID de usuário na configuração do Kubernetes
- Não importa qual é o nome de usuário ou ID numérico, ou se é o mesmo ID de usuário que existe em outro contêiner ou no host, desde que o uid numérico não seja 0
O único lugar onde há um problema prático é se o contêiner tenta armazenar dados em um volume. Novamente, o caso ideal seria evitar isso totalmente; prefira usar um banco de dados ou armazenamento em nuvem, se houver possibilidade.
Se você precisar usar um volume local, poderá configurar especificamente uma política de segurança com um suplemento fsGroup:. Esse é um ID de grupo numérico arbitrário (não o ID do usuário) que possuirá os arquivos no volume e também será adicionado à lista de grupos para o processo do contêiner principal.
apiVersion: v1
kind: Pod
spec:
securityContext:
fsGroup: 12345 # or any numeric gid
Não use hostPathvolumes de forma alguma: você não pode garantir que o mesmo conteúdo estará em todos os nós se o pod for reprogramado e, se o nó falhar, o conteúdo que reside apenas naquele nó será perdido.