Passos

O autor selecionou a Open Sourcing Mental Illness para receber uma doação como parte do programa Write for DOnations.

Introdução

O Kubernetes, a plataforma de orquestração de contêineres de código aberto, tem se tornado a solução preferida para automatização, ampliação e gerenciamento de clusters de alta disponibilidade. Como resultado de sua popularidade crescente, a segurança do Kubernetes tornou-se cada vez mais relevante.

Considerando as partes que se movem envolvidas no Kubernetes e os vários cenários de implantação, proteger o Kubernetes pode ser por vezes complexo. Por isso, o objetivo deste artigo é fornecer uma base de segurança sólida para um cluster Kubernetes da DigitalOcean (DOKS). Note que este tutorial aborda as medidas de segurança básicas para o Kubernetes e deve ser um ponto de partida em vez de um guia exaustivo. Para obter passos adicionais, consulte a documentação oficial do Kubernetes.

Neste guia, você fará os passos básicos para proteger seu cluster Kubernetes da DigitalOcean. Você configurará a autenticação local segura com certificados TLS/SSL, concederá permissões aos usuários locais com os controles de acesso baseados em papel (RBAC), permissões para aplicativos e implantações do Kubernetes com contas de serviço e configurará os limites de recurso com os contêineres de admissão ResourceQuota e LimitRange.

Pré-requisitos

Para completar este tutorial, você precisará de:

Passo 1 — Habilitando a autenticação de usuário remoto

Após completar os pré-requisitos, você terá um superusuário Kubernetes que se autentica por meio de um token pré-definido ao portador da DigitalOcean. No entanto, compartilhar essas credenciais não é uma boa prática de segurança, uma vez que essa conta pode causar alterações importantes e possivelmente destrutivas no seu cluster. Para mitigar essa possibilidade, configure usuários adicionais a serem autenticados a partir dos seus respectivos clientes locais.

Nesta seção, você autenticará novos usuários para o cluster DOKS remoto de clientes locais usando certificados SSL/TLS seguros. Este será um processo de três passos: primeiro, você criará as Solicitações de assinatura de certificados (CSR) para cada usuário e, em seguida, aprovará esses certificados diretamente no cluster através do kubectl. Por fim, você construirá para cada usuário um arquivo kubeconfig com os certificados apropriados. Para obter mais informações sobre métodos de autenticação adicionais compatíveis com o Kubernetes, consulte a documentação de autenticação do Kubernetes.

Como criar pedidos de assinatura de certificados para novos usuários

Antes de começar, verifique a conexão de cluster DOKS a partir da máquina local configurada durante os pré-requisitos:

Dependendo da sua configuração, o resultado será semelhante a este:

Output
Kubernetes master is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com
CoreDNS is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Isso significa que você está conectado ao cluster DOKS.

Em seguida, crie uma pasta local para os certificados do cliente. Para os fins deste guia, o ~/certs será usado para armazenar todos os certificados:

Neste tutorial, vamos autorizar um novo usuário chamado sammy para acessar o cluster. Sinta-se à vontade para alterar isso para um usuário de sua escolha. Usando a biblioteca SSL e TLS OpenSSL, gere uma nova chave privada para seu usuário usando o seguinte comando:

openssl genrsa -out ~/certs/sammy.key 4096

A flag -out criará o arquivo de saída ~/certs/sammy.key, e 4096 define a chave como 4096-bit. Para obter mais informações sobre o OpenSSL, consulte nosso guia Fundamentos do OpenSSL.

Agora, crie um arquivo de configuração para solicitação de assinatura de certificado. Abra o arquivo a seguir com um editor de texto (para este tutorial, usaremos o nano):

nano ~/certs/sammy.csr.cnf

Adicione o seguinte conteúdo ao arquivo sammy.csr.cnf para especificar no assunto o nome de usuário desejado como nome comum (CN) e o grupo como organização (O):

~/certs/sammy.csr.cnf

[ req ]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
[ dn ]
CN = sammy
O = developers
[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth

O arquivo de configuração de solicitação de assinatura de certificado contém todas as informações necessárias, identidade do usuário e os parâmetros de uso adequados para o usuário. O último argumento extendedKeyUsage=serverAuth,clientAuth permitirá que os usuários autentiquem seus clientes locais com o cluster DOKS usando o certificado assim que ele estiver assinado.

Em seguida, crie a solicitação de assinatura de certificado sammy:

openssl req -config ~/certs/sammy.csr.cnf -new -key ~/certs/sammy.key -nodes -out ~/certs/sammy.csr

O -config permite que você especifique o arquivo de configuração para o CSR, e -new sinaliza que você está criando uma nova CSR para a chave especificada por -key.

Verifique sua solicitação de assinatura de certificado executando o seguinte comando:

openssl req -in ~/certs/sammy.csr -noout -text

Aqui, você envia o CSR com -in e usa -text para imprimir a solicitação de certificado em texto.

O resultado mostrará a solicitação de certificado, cujo início se parecerá com este:

Output
Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: CN = sammy, O = developers
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
...

Repita o mesmo procedimento para criar CSRs para quaisquer usuários adicionais. Assim que tiver todas as solicitações de assinatura de certificado salvas na pasta ~/certs do administrador, prossiga com o próximo passo para aprová-las.

Como gerenciar pedidos de assinatura de certificado com a API do Kubernetes

Você pode aprovar ou negar os certificados TLS emitidos para a API do Kubernetes usando a ferramenta de linha de comando kubectl. Isso dá a você a capacidade de garantir que o acesso solicitado é apropriado para um determinado usuário. Nesta seção, você enviará e aprovará a solicitação de certificado para sammy.

Para enviar uma CSR para o cluster DOKS, use o seguinte comando:

cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
  name: sammy-authentication
spec:
  groups:
  - system:authenticated
  request: $(cat ~/certs/sammy.csr | base64 | tr -d 'n')
  usages:
  - digital signature
  - key encipherment
  - server auth
  - client auth
EOF

Usando um here document Bash, este comando usa o cat para passar a solicitação de certificado para o kubectl apply.

Vamos dar uma olhada de perto na solicitação de certificado:

• name: sammy-authentication cria um identificador de metadados, neste caso chamado sammy-authentication.
• request: $(cat ~/certs/sammy.csr | base64 | tr -d 'n') envia a solicitação de assinatura de certificado sammy.csr para o cluster codificado como Base64.
• server auth e client auth especificam o uso pretendido do certificado. Neste caso, o propósito é a autenticação de usuário.

O resultado será semelhante a este:

Output
certificatesigningrequest.certificates.k8s.io/sammy-authentication created

Você pode verificar o status da solicitação de assinatura de certificado usando o comando:

Dependendo da sua configuração de cluster, o resultado será semelhante a este:

Output
NAME                   AGE   REQUESTOR                 CONDITION
sammy-authentication   37s   your_DO_email    Pending

Em seguida, aprove o CSR usando o comando:

kubectl certificate approve sammy-authentication

Você receberá uma mensagem confirmando a operação:

Output
certificatesigningrequest.certificates.k8s.io/sammy-authentication approved

Nota: como administrador, você também pode negar uma CSR usando o comando kubectl certificate deny sammy-authentication. Para obter mais informações sobre como gerenciar certificados TLS, leia a documentação oficial do Kubernetes.


Agora que a CSR está aprovada, baixe-a para a máquina local, executando:

kubectl get csr sammy-authentication -o jsonpath='{.status.certificate}' | base64 --decode > ~/certs/sammy.crt

Este comando decodifica o certificado Base64 para uso adequado pelo kubectl e, em seguida, salva-o como ~/certs/sammy.crt.

Com o certificado sammy assinado em mãos, agora é possível construir o arquivo kubeconfig do usuário.

Como construir o kubeconfig de usuários remotos

Em seguida, você criará um arquivo kubeconfig específico para o usuário sammy. Isso dará mais controle sobre o acesso do usuário ao seu cluster.

O primeiro passo na construção de um novo kubeconfig é fazer uma cópia do arquivo kubeconfig atual. Para os fins deste guia, o novo arquivo kubeconfig será chamado de config-sammy:

cp ~/.kube/config ~/.kube/config-sammy

Em seguida, edite o novo arquivo:

nano ~/.kube/config-sammy

Mantenha as primeiras oito linhas deste arquivo, uma vez que elas contêm as informações necessárias para a conexão SSL/TLS com o cluster. Então, começando a partir do parâmetro de user, substitua o texto pelas linhas destacadas a seguir, para que o arquivo seja semelhante ao seguinte:

config-sammy

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: certificate_data
  name: do-nyc1-do-cluster
contexts:
- context:
    cluster: do-nyc1-do-cluster
    user: sammy
  name: do-nyc1-do-cluster
current-context: do-nyc1-do-cluster
kind: Config
preferences: {}
users:
- name: sammy
  user:
    client-certificate: /home/your_local_user/certs/sammy.crt
    client-key: /home/your_local_user/certs/sammy.key

Nota: para o client-certificate e client-key, use o caminho absoluto para sua localização de certificado correspondente. Caso contrário, o kubectl gerará um erro.


Salve e saia do arquivo.

É possível testar a nova conexão de usuário usando kubectl cluster-info:

kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy cluster-info

Você verá um erro semelhante a este:

Output
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
Error from server (Forbidden): services is forbidden: User "sammy" cannot list resource "services" in API group "" in the namespace "kube-system"

Este erro é esperado, pois o usuário sammy ainda não tem permissão para listar qualquer recurso no cluster. Como conceder a autorização para usuários será abordado no próximo passo. Por enquanto, o resultado está confirmando que a conexão SSL/TLS foi bem-sucedida e as credenciais de autenticação sammy foram aceitas pela API do Kubernetes.

Passo 2 — Autorizando usuários por meio do Controle de acesso baseado em papel (RBAC)

Assim que um usuário for autenticado, a API determina as permissões dela usando o modelo de controle de acesso baseado em papel (RBAC) do Kubernetes. O RBAC é um método eficaz para restringir os direitos de usuário, baseando-se no papel atribuído a ele. De um ponto de vista de segurança, o RBAC permite configurar permissões de dados refinadas para limitar os usuários de acessar dados confidenciais ou executar comandos de superusuário. Para obter informações mais detalhadas sobre os papéis de usuário, consulte a documentação RBAC do Kubernetes.

Neste passo, você usará o kubectl para atribuir o papel pré-definido edit para o usuário sammy no namespace default. Em um ambiente de produção, você pode querer usar papéis personalizados e/ou atribuições de papel personalizadas.

Como conceder permissões

No Kubernetes, conceder permissões significa atribuir o papel desejado a um usuário. Atribua permissões edit para o usuário sammy no namespace default usando o seguinte comando:

kubectl create rolebinding sammy-edit-role --clusterrole=edit --user=sammy --namespace=default

Isso dará um resultado similar ao seguinte:

Output
rolebinding.rbac.authorization.k8s.io/sammy-edit-role created

Vamos analisar este comando em mais detalhes:

• create rolebinding sammy-edit-role cria uma nova atribuição de papel, neste caso chamado sammy-edit-role.
• --clusterrole=edit atribui o papel pré-definido edit em um escopo global (papel do cluster).
• --user=sammy especifica a qual usuário vincular o papel.
• --namespace=default concede ao usuário permissões de papel dentro do namespace especificado, neste caso, default.

Em seguida, verifique as permissões de usuários listando os pods no namespace default. Você pode dizer que a autorização RBAC está funcionando como esperado se nenhum erro for mostrado.

kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy auth can-i get pods

Você receberá o seguinte resultado:

Output
yes

Agora que você atribuiu permissões para sammy, pratique a revogação dessas permissões na seção seguinte.

Como revogar permissões

A revogação de permissões é feita no Kubernetes removendo o papel do usuário.

Para este tutorial, delete o papel edit do usuário sammy, executando o seguinte comando:

kubectl delete rolebinding sammy-edit-role

Você receberá o seguinte resultado:

Output
rolebinding.rbac.authorization.k8s.io "sammy-edit-role" deleted

Verifique se as permissões de usuário foram revogadas como esperado listando os pods do namespace default:

kubectl --kubeconfig=/home/localuser/.kube/config-sammy --namespace=default get pods

Você receberá o seguintes erro:

Output
Error from server (Forbidden): pods is forbidden: User "sammy" cannot list resource "pods" in API group "" in the namespace "default"

Isso mostra que a autorização foi revogada.

Do ponto de vista de segurança, o modelo de autorização do Kubernetes dá aos administradores de cluster a flexibilidade para alterar os direitos de usuários sob demanda, conforme necessário. Além disso, o controle de acesso baseado em papel não se limita a um usuário físico; você também pode conceder e remover permissões aos serviços de cluster, como aprenderá na seção seguinte.

Para obter mais informações sobre a autorização RBAC e como criar papéis personalizados, leia a documentação oficial.

Como mencionado na seção anterior, os mecanismos de autorização do RBAC se estendem para além de usuários humanos. Usuários de cluster não humanos, como aplicativos, serviços e processos em execução dentro de pods, autenticam-se com a API do servidor usando o que o Kubernetes chama de contas de serviço. Quando um pod é criado dentro de um namespace, você pode deixá-lo usar a conta de serviço default ou definir uma conta de serviço de sua escolha. A capacidade de atribuir CSs individuais aos aplicativos e processos dá aos administradores a liberdade de concessão ou revogação de permissões, conforme necessário. Além disso, atribuir CSs específicas para aplicativos críticos para a produção é considerada uma prática recomendada de segurança. Como usa-se contas de serviço para autenticação e, assim, para as checagens de autorização do RBAC, os administradores de clusters contém ameaças de segurança por meio da alteração de direitos de acesso de conta de serviço e isolamento do processo de ofensa.

Para demonstrar contas de serviço, este tutorial usará um servidor Web do Nginx como um aplicativo de amostra.

Antes de atribuir uma CS particular para seu aplicativo, é necessário criar a CS. Crie uma nova conta de serviço chamada nginx-sa no namespace default:

kubectl create sa nginx-sa

Você receberá:

Output
serviceaccount/nginx-sa created

Verifique se a conta de serviço foi criada executando o seguinte:

Isso dará a você uma lista de suas contas de serviço:

Output
NAME       SECRETS   AGE
default    1         22h
nginx-sa   1         80s

Agora, você atribuirá um papel para a conta de serviço nginx-sa. Para este exemplo, conceda a nginx-sa as mesmas permissões que o usuário sammy:

kubectl create rolebinding nginx-sa-edit 
 --clusterrole=edit 
 --serviceaccount=default:nginx-sa 
 --namespace=default

Ao executar isso, obtêm-se o seguinte:

Output
rolebinding.rbac.authorization.k8s.io/nginx-sa-edit created

Esse comando usa o mesmo formato que para o usuário sammy, exceto pela flag --serviceaccount=default:nginx-sa, onde você atribui a conta de serviço nginx-sa no namespace default.

Verifique se a vinculação de papel foi bem-sucedida usando este comando:

Isso dará o seguinte resultado:

Output
NAME            AGE
nginx-sa-edit   23s

Assim que tiver confirmado que a atribuição de papel para a conta de serviço foi configurada com sucesso, é possível atribuir a conta de serviço a um aplicativo. Atribuir uma conta de serviço particular para um aplicativo permitirá que você gerencie seus direitos de acesso em tempo real e, portanto, reforce a segurança do cluster.

Para os fins deste tutorial, um pod nginx servirá como aplicativo de amostra. Crie o novo pod e especifique a conta de serviço nginx-sa com o seguinte comando:

kubectl run nginx --image=nginx --port 80 --serviceaccount="nginx-sa"

A primeira parte do comando cria um novo pod que é executado no servidor Web nginx na porta :80, e a última porção --serviceaccount="nginx-sa" indica que este pod deve usar a conta de serviço nginx-sa e não a CS default.

Isso gerará um resultado similar ao seguinte:

Output
deployment.apps/nginx created

Verifique se o novo aplicativo está usando a conta de serviço, usando kubectl describe:

kubectl describe deployment nginx

Isso gerará uma descrição longa dos parâmetros de implantação. Na seção Pod Template, você verá um resultado semelhante a este:

Output
...
Pod Template:
 Labels: run=nginx
 Service Account: nginx-sa
...

Nesta seção, você criou a conta de serviço nginx-sa no namespace default e a atribuiu ao servidor nginx. Agora, é possível controlar permissões do nginx em tempo real, modificando o papel dele conforme necessário. Também é possível agrupar aplicativos atribuindo a mesma conta de serviço a cada um e, em seguida, fazer alterações de maior peso na permissões. Por fim, seria possível isolar aplicativos críticos, atribuindo-lhes uma CS única.

Resumindo, a ideia por trás da atribuição de papéis para seus aplicativos/implantações é ajustar em detalhes as permissões. Em ambientes de produção real, você pode ter várias implantações que requerem permissões diferentes, que vão desde apenas leitura até privilégios administrativos completos. Usar o RBAC traz a flexibilidade para restringir o acesso ao cluster conforme necessário.

Em seguida, você configurará controladores de admissão para controlar recursos e protegê-los contra os ataques de esgotamento de recursos.

Passo 4 — Configurando os controladores de admissão

Os controladores de admissão do Kubernetes são plug-ins opcionais compilados no binário kube-apiserver para expandir as opções de segurança. Os controladores de admissão interceptam solicitações após elas passarem a fase de autenticação e autorização. Assim que a solicitação é interceptada, os controladores de admissão executam o código especificado pouco antes da solicitação ser aplicada.

Embora o resultado de uma verificação de autenticação ou autorização seja um booleano que permite ou nega a solicitação, os controladores de admissão podem ser muito mais variados. Os controladores de admissão podem validar solicitações da mesma forma que a autenticação, mas também podem alterar ou mudar os pedidos e modificar os objetos antes de serem admitidos.

Neste passo, você usará os controladores de admissão ResourceQuota e LimitRange para proteger seu cluster, mudando solicitações que poderiam contribuir para um ataque de esgotamento de recursos ou de negação de serviço. O controlador de admissão ResourceQuota permite que os administradores restrinjam os recursos de computação, recursos de armazenamento e a quantidade de qualquer objeto dentro de um namespace, ao passo que o controlador de admissão LimitRange limitará o número de recursos usados pelos contêineres. Usar esses dois controladores de admissão juntos protegerá seu cluster de ataques que tornariam seus recursos indisponíveis.

Para demonstrar como funciona o ResourceQuota, você implementará algumas restrições no namespace default. Comece criando um novo arquivo de objeto do ResourceQuota:

nano resource-quota-default.yaml

Adicione a definição de objeto a seguir no conjunto de restrições para o consumo de recursos no namespace default. Você pode ajustar os valores conforme necessário, dependendo dos recursos físicos dos seus nós:

resource-quota-default.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-quota-default
spec:
  hard:
    pods: "2"
    requests.cpu: "500m"
    requests.memory: 1Gi
    limits.cpu: "1000m"
    limits.memory: 2Gi
    configmaps: "5"
    persistentvolumeclaims: "2"
    replicationcontrollers: "10"
    secrets: "3"
    services: "4"
    services.loadbalancers: "2"

Esta definição usa a palavra-chave hard para definir restrições severas, como o número máximo de pods, configmaps, PersistentVolumeClaims, ReplicationControllers, secrets, services e loadbalancers. Ela também define os limites dos recursos de computação, como:

• requests.cpu, que define o valor máximo de CPU dos pedidos em milliCPU, ou um milésimo de um núcleo da CPU.
• requests.memory, que define o valor máximo de memória dos pedidos em bytes.
• limits.cpu, que define o valor máximo de CPU dos limites em milliCPUs.
• limits.memory, que define o valor máximo de memória dos limites em bytes.

Salve e saia do arquivo.

Agora, crie o objeto no namespace, executando o seguinte comando:

kubectl create -f resource-quota-default.yaml --namespace=default

Isso irá resultar no seguinte:

Output
resourcequota/resource-quota-default created

Note que você está usando a flag -f para indicar ao Kubernetes o local do arquivo ResourceQuota e a flag --namespace para especificar qual espaço de nomes será atualizado.

Assim que o objeto for criado, seu ResourceQuota estará ativo. Você pode verificar as quotas do namespace default com describe quota:

kubectl describe quota --namespace=default

O resultado será semelhante a este, com os limites severos que você definiu no arquivo resource-quota-default.yaml:

Output
Name:                   resource-quota-default
Namespace:              default
Resource                Used  Hard
--------                ----  ----
configmaps              0     5
limits.cpu              0     1
limits.memory           0     2Gi
persistentvolumeclaims  0     2
pods                    1     2
replicationcontrollers  0     10
requests.cpu            0     500m
requests.memory         0     1Gi
secrets                 2     3
services                1     4
services.loadbalancers  0     2

ResourceQuotas são expressos em unidades absolutas, então, adicionar nós adicionais não aumentará automaticamente os valores definidos aqui. Se mais nós forem adicionados, você precisará editar manualmente os valores aqui para providenciar os recursos. ResourceQuotas podem ser modificados sempre que precisar, mas não podem ser removidos, a menos que todo o namespace seja removido.

Se precisar modificar um ResourceQuota em particular, atualize o arquivo .yaml correspondente e aplique as alterações usando o seguinte comando:

kubectl apply -f resource-quota-default.yaml --namespace=default

Para obter mais informações sobre o controlador de admissão ResourceQuota, consulte a documentação oficial.

Agora que seu ResourceQuota está configurado, continue adiante para configurar o controlador de admissão LimitRange. De maneira similar a como o ResourceQuota aplica limites nos namespaces, o LimitRange aplica as limitações declaradas, pela validação e alteração de contêineres.

De forma parecida como feito antes, comece criando o arquivo de objeto:

nano limit-range-default.yaml

Agora, utilize o objeto LimitRange para restringir o uso de recursos conforme necessário. Adicione o conteúdo a seguir como exemplo de um caso de uso típico:

limit-ranges-default.yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: limit-range-default
spec:
  limits:
  - max:
      cpu: "400m"
      memory: "1Gi"
    min:
      cpu: "100m"
      memory: "100Mi"
    default:
      cpu: "250m"
      memory: "800Mi"
    defaultRequest:
      cpu: "150m"
      memory: "256Mi"
    type: Container

Os valores amostrais usados em limit-ranges-default.yaml restringem a memória do contêiner a um máximo de 1Gi e limita o uso de CPU a um máximo de 400m, que é equivalente a 400 milliCPU, o que significa que o contêiner fica limitado a usar quase metade do seu núcleo.

Em seguida, implante o objeto no servidor da API, usando o seguinte comando:

kubectl create -f limit-range-default.yaml --namespace=default

Isso dará o seguinte resultado:

Output
limitrange/limit-range-default created

Agora, verifique os novos limites com o seguinte comando:

kubectl describe limits --namespace=default

Seu resultado será semelhante a este:

Output
Name:       limit-range-default
Namespace:  default
Type        Resource  Min    Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------  ---    ---   ---------------  -------------  -----------------------
Container   cpu       100m   400m  150m             250m           -
Container   memory    100Mi  1Gi   256Mi            800Mi          -

Para ver o LimitRanger em ação, implante um contêiner nginx padrão com o seguinte comando:

kubectl run nginx --image=nginx --port=80 --restart=Never

Isso dará o seguinte resultado:

Output
pod/nginx created

Note como o controlador de admissão transformou o contêiner, executando o seguinte comando:

kubectl get pod nginx -o yaml

Isso gerará muitas linhas como resultado. Procure na seção de especificação do contêiner para encontrar os limites de recurso especificados no controlador de admissão LimitRange:

Output
...
spec:
  containers:
  - image: nginx
  imagePullPolicy: IfNotPresent
  name: nginx
  ports:
  - containerPort: 80
    protocol: TCP
  resources:
    limits:
      cpu: 250m
      memory: 800Mi
    requests:
      cpu: 150m
      memory: 256Mi
...

Seria a mesma coisa caso tivesse declarado manualmente os resources e requests na especificação do contêiner.

Neste passo, você usou os controladores de admissão ResourceQuota e LimitRange para se proteger contra ataques mal-intencionados que visam os recursos do seu cluster. Para obter mais informações sobre o controlador de admissão LimitRange, leia a documentação oficial.

Conclusão

Ao longo deste guia, você configurou um modelo de segurança do Kubernetes básico. Ele estabeleceu a autenticação e a autorização do usuário, privilégios de aplicativo e proteção de recursos do cluster. Pela combinação de todas as sugestões abrangidas neste artigo, você terá uma base sólida para uma implantação de cluster do Kubernetes na produção. A partir daí, você pode começar a solidificar outros aspectos individuais do seu cluster, dependendo do seu cenário.

Se quiser aprender mais sobre o Kubernetes, confira nossa página de recursos do Kubernetes, ou siga nosso curso auto-guiado Kubernetes para desenvolvedores full-stack.