Neste documento, descrevemos como aumentar a segurança dos clusters do Anthos em clusters bare metal.
Proteger seus contêineres usando o SELinux
É possível proteger seus contêineres ativando o SELinux, que é compatível com o Red Hat Enterprise Linux (RHEL) e o CentOS. Se as máquinas host estiverem executando o RHEL ou o CentOS e você quiser ativar o SELinux no cluster, ative o SELinux em todas as máquinas host. Para mais detalhes, veja proteger seus contêineres usando o SELinux.
Não execute contêineres como usuário root
Por padrão, os processos em contêineres são executados como root. Isso representa um possível problema de segurança porque, se um processo sair do contêiner, ele será executado como raiz na máquina host. Portanto, é aconselhável executar todas as cargas de trabalho como um usuário não raiz.
As seções a seguir descrevem duas maneiras de executar contêineres como um usuário não raiz.
Método 1: adicionar a instrução USER em Dockerfile
Esse método usa um Dockerfile para garantir que os contêineres não sejam executados como um usuário root. Em um Dockerfile, é possível especificar em qual usuário o processo
em um contêiner será executado. O snippet a seguir de um Dockerfile mostra como fazer isso:
....
#Add a user with userid 8877 and name nonroot
RUN useradd −u 8877 nonroot
#Run Container as nonroot
USER nonroot
....
Neste exemplo, o comando useradd -u do Linux cria um usuário chamado nonroot
dentro do contêiner. O usuário tem um ID de usuário (UID) 8877.
A próxima linha no Dockerfile executa o comando USER nonroot. Esse comando especifica que, a partir desse ponto, na imagem, os comandos são executados como o usuário nonroot.
Conceda permissões ao UID 8877 para que os processos de contêiner possam ser executados
corretamente para nonroot.
Método 2: adicionar campos "securityContext" ao arquivo de manifesto do Kubernetes
Esse método usa um arquivo de manifesto do Kubernetes para garantir que os contêineres não sejam executados como um usuário root. As configurações de segurança são especificadas para um pod e, por sua vez, essas configurações são aplicadas a todos os contêineres dentro do pod.
O exemplo a seguir mostra um trecho de um arquivo de manifesto de um determinado pod:
apiVersion: v1
kind: Pod
metadata:
name: name-of-pod
spec:
securityContext:
runAsUser: 8877
runAsGroup: 8877
....
O campo runAsUser especifica que, para qualquer contêiner no pod, todos os processos são executados com o ID do usuário 8877. O campo runAsGroup especifica que esses processos têm um ID do grupo principal (GID) de 8877. Lembre-se de conceder as permissões necessárias e suficientes para o UID 8877 para que os processos de contêiner possam ser executados corretamente.
Isso garante que os processos dentro de um contêiner sejam executados como UID 8877, que tem menos privilégios que a raiz.
Os contêineres do sistema em clusters do Anthos em Bare Metal usam UIDs e GIDs no intervalo 2000-4999. Portanto, use UIDs e GIDs que não estejam nesse intervalo reservado quando atribuir permissões às cargas de trabalho do usuário.
Restringir a capacidade de automodificação das cargas de trabalho
Certas cargas de trabalho do Kubernetes, principalmente as cargas de trabalho do sistema, têm permissão para se automodificar. Por exemplo, algumas cargas de trabalho escalonam automaticamente na vertical. Embora seja conveniente, isso pode permitir que um invasor que já tenha comprometido um nó escalone ainda mais no cluster. Por exemplo, um invasor pode fazer com que uma carga de trabalho do nó se automodifique para ser executada como uma conta de serviço com mais privilégios que existe no mesmo namespace.
O ideal é que as cargas de trabalho não recebam permissão para se automodificar. Quando a automodificação for necessária, limite as permissões aplicando restrições do Gatekeeper ou do Policy Controller, como NoUpdateServiceAccount da biblioteca de código aberto do Gatekeeper, que fornece várias medidas de segurança úteis.
Ao implantar políticas, geralmente é necessário permitir que os controladores que
gerenciam o ciclo de vida do cluster ignorem as políticas. Isso é necessário para que
os controladores possam fazer alterações no cluster, como a aplicação de upgrades
de cluster. Por exemplo, se você implantar a política NoUpdateServiceAccount em
clusters do Anthos em Bare Metal, será necessário definir os seguintes parâmetros no Constraint:
parameters:
allowedGroups:
- system:masters
allowedUsers: []
Manutenção
O monitoramento de boletins de segurança e o upgrade dos clusters são medidas importantes de segurança depois que os clusters estiverem funcionando.
Monitorar boletins de segurança
A equipe de segurança do Anthos publica boletins de segurança para vulnerabilidades de gravidade alta e crítica.
Estes boletins seguem um esquema de numeração de vulnerabilidade
comum do Google Cloud e estão vinculados na página principal de boletins do Google Cloud e
nas notas da versão dos clusters do Anthos no Bare Metal. Use este feed XML para se inscrever em boletins
de segurança para clusters do Anthos em produtos bare metal e relacionados:
https://cloud.google.com/feeds/anthos-gke-security-bulletins.xml 
Quando a ação do cliente for necessária para resolver essas vulnerabilidades desse tipo, o Google entrará em contato com os clientes por e-mail. Além disso, o Google também pode entrar em contato com os clientes por meio de contratos de suporte por meio de canais de suporte.
Para mais informações sobre como o Google gerencia vulnerabilidades e patches de segurança para o GKE e o Anthos, consulte Patches de segurança.
Fazer upgrade de clusters
O Kubernetes apresenta frequentemente novos recursos de segurança e fornece patches de segurança. Os clusters do Anthos em versões bare metal incorporam melhorias de segurança do Kubernetes que abordam as vulnerabilidades de segurança que podem afetar seus clusters.
Você é responsável por manter os clusters do Anthos atualizados. Para cada versão, leia as notas da versão. Para minimizar os riscos de segurança aos clusters do Anthos, planeje a atualização para novas versões de patch a cada mês e versões secundárias a cada três meses.
Uma das muitas vantagens de fazer upgrade de um cluster é que ele atualiza automaticamente
o arquivo kubeconfig dele. O arquivo kubeconfig autentica um
usuário em um cluster. O arquivo kubeconfig é adicionado ao diretório do cluster quando
você cria um cluster com bmctl. O nome e o caminho padrão são
bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.
Quando você faz o upgrade de um cluster, o arquivo kubeconfig dele é renovado
automaticamente. Caso contrário, o arquivo kubeconfig expira um ano após a criação.
Para ver informações sobre como fazer upgrade dos clusters, consulte Fazer upgrade dos clusters.