O autor selecionou a Open Sourcing Mental Illness para receber uma doação como parte do programa Write for DOnations.
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
.
Para completar este tutorial, você precisará de:
~/.kube/config
. Para obter instruções detalhadas sobre como configurar o gerenciamento remoto do DOKS, leia nosso guia Como se conectar a um cluster Kubernetes da DigitalOcean. Em particular, você precisará de:
kubectl
instalada em sua máquina local. Você pode ler mais sobre como instalar e configurar o kubectl
em sua documentação oficial. Este tutorial usará o kubectl
versão 1.17.0-00.doctl
. Para obter instruções sobre como instalá-lo, consulte a página do doctl
no GitHub. Este tutorial usará o doctl
versão 1.36.0.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.
Antes de começar, verifique a conexão de cluster DOKS a partir da máquina local configurada durante os pré-requisitos:
- kubectl cluster-info
Dependendo da sua configuração, o resultado será semelhante a este:
OutputKubernetes 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:
- mkdir ~/certs
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):
[ 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:
OutputCertificate 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.
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:
Outputcertificatesigningrequest.certificates.k8s.io/sammy-authentication created
Você pode verificar o status da solicitação de assinatura de certificado usando o comando:
- kubectl get csr
Dependendo da sua configuração de cluster, o resultado será semelhante a este:
OutputNAME 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:
Outputcertificatesigningrequest.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.
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:
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:
OutputTo 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.
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.
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:
Outputrolebinding.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:
Outputyes
Agora que você atribuiu permissões para sammy, pratique a revogação dessas permissões na seção seguinte.
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:
Outputrolebinding.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:
OutputError 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á:
Outputserviceaccount/nginx-sa created
Verifique se a conta de serviço foi criada executando o seguinte:
- kubectl get sa
Isso dará a você uma lista de suas contas de serviço:
OutputNAME 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:
Outputrolebinding.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:
- kubectl get rolebinding
Isso dará o seguinte resultado:
OutputNAME 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:
Outputdeployment.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.
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:
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:
Outputresourcequota/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
:
OutputName: 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:
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:
Outputlimitrange/limit-range-default created
Agora, verifique os novos limites com o seguinte comando:
- kubectl describe limits --namespace=default
Seu resultado será semelhante a este:
OutputName: 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:
Outputpod/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.
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.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Sign up for Infrastructure as a Newsletter.
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.