Segurança do pod - Amazon EKS
Capacidades do LinuxSoluções de segurança para PodRecomendaçõesFerramentas e recursos

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Segurança do pod

A especificação do pod inclui uma variedade de atributos diferentes que podem fortalecer ou enfraquecer sua postura geral de segurança. Como praticante do Kubernetes, sua principal preocupação deve ser evitar que um processo executado em um contêiner escape dos limites de isolamento do tempo de execução do contêiner e tenha acesso ao host subjacente.

Capacidades do Linux

Os processos executados em um contêiner são executados sob o contexto do usuário raiz [Linux] por padrão. Embora as ações do root em um contêiner sejam parcialmente restringidas pelo conjunto de recursos do Linux que o tempo de execução do contêiner atribui aos contêineres, esses privilégios padrão podem permitir que um invasor aumente seus privilégios e/ou tenha acesso a informações confidenciais vinculadas ao host, incluindo segredos e. ConfigMaps Abaixo está uma lista dos recursos padrão atribuídos aos contêineres. Para obter informações adicionais sobre cada recurso, consulte http://man7. org/linux/man-pages/man7/capabilities.7.html.

CAP_AUDIT_WRITE, CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_FSETID, CAP_KILL, CAP_MKNOD, CAP_NET_BIND_SERVICE, CAP_NET_RAW, CAP_SETGID, CAP_SETUID, CAP_SETFCAP, CAP_SETPCAP, CAP_SYS_CHROOT

EC2 e os pods Fargate recebem os recursos mencionados acima por padrão. Além disso, os recursos do Linux só podem ser removidos dos pods do Fargate.

Os pods que são executados com privilégios herdam todos os recursos do Linux associados ao root no host. Isso deve ser evitado, se possível.

Autorização do Node

Todos os nós de trabalho do Kubernetes usam um modo de autorização chamado Node Authorization. A autorização de nós autoriza todas as solicitações de API originadas do kubelet e permite que os nós executem as seguintes ações:

Operações de leitura:

  • serviços

  • endpoints

  • nós

  • vagens

  • segredos, configmaps, declarações de volume persistentes e volumes persistentes relacionados a pods vinculados ao nó do kubelet

Operações de gravação:

  • nós e status do nó (habilite o plug-in de NodeRestriction admissão para limitar um kubelet a modificar seu próprio nó)

  • pods e status do pod (habilite o plug-in de NodeRestriction admissão para limitar um kubelet a modificar pods vinculados a si mesmo)

  • eventos

Operações relacionadas à autenticação:

  • Acesso de leitura/gravação à API CertificateSigningRequest (CSR) para inicialização de TLS

  • a capacidade de criar TokenReview e SubjectAccessReview para cheques delegados authentication/authorization

O EKS usa o controlador de admissão de restrição de nós, que só permite que o nó modifique um conjunto limitado de atributos do nó e objetos do pod que estão vinculados ao nó. No entanto, um invasor que conseguir acessar o host ainda poderá obter informações confidenciais sobre o ambiente da API do Kubernetes, o que poderia permitir que ele se movesse lateralmente dentro do cluster.

Soluções de segurança para Pod

Política de segurança do Pod (PSP)

No passado, os recursos da Política de Segurança do Pod (PSP) eram usados para especificar um conjunto de requisitos que os pods precisavam atender antes de serem criados. A partir da versão 1.21 do Kubernetes, o PSP foi descontinuado. Eles estão programados para remoção na versão 1.25 do Kubernetes.

Importante

PSPs estão obsoletos na versão 1.21 do Kubernetes. Você terá até a versão 1.25 ou aproximadamente 2 anos para fazer a transição para uma alternativa. Este documento explica a motivação para essa suspensão de uso.

Migração para uma nova solução de segurança de pod

Como PSPs foram removidos a partir do Kubernetes v1.25, os administradores e operadores de cluster devem substituir esses controles de segurança. Duas soluções podem preencher essa necessidade:

As soluções PAC e PSS podem coexistir com o PSP; elas podem ser usadas em clusters antes que o PSP seja removido. Isso facilita a adoção ao migrar do PSP. Consulte este documento ao considerar a migração do PSP para o PSS.

A Kyverno, uma das soluções de PAC descritas abaixo, tem orientações específicas descritas em uma postagem no blog ao migrar de sua solução PSPs para sua solução, incluindo políticas análogas, comparações de recursos e um procedimento de migração. Informações e orientações adicionais sobre migração para Kyverno com relação ao Pod Security Admission (PSA) foram publicadas no blog da AWS aqui.

Policy-as-code (PAC)

Policy-as-code As soluções (PAC) fornecem proteções para orientar os usuários do cluster e evitar comportamentos indesejados por meio de controles prescritos e automatizados. O PAC usa Kubernetes Dynamic Admission Controllers para interceptar o fluxo de solicitações do servidor da API Kubernetes, por meio de uma chamada de webhook, e alterar e validar as cargas de solicitação, com base em políticas escritas e armazenadas como código. A mutação e a validação acontecem antes que a solicitação do servidor da API resulte em uma alteração no cluster. As soluções PAC usam políticas para combinar e agir sobre as cargas de solicitação do servidor de API, com base na taxonomia e nos valores.

Há várias soluções de PAC de código aberto disponíveis para o Kubernetes. Essas soluções não fazem parte do projeto Kubernetes; elas são provenientes do ecossistema Kubernetes. Algumas soluções de PAC estão listadas abaixo.

Para obter mais informações sobre as soluções PAC e como ajudá-lo a selecionar a solução adequada às suas necessidades, consulte os links abaixo.

Padrões de segurança do pod (PSS) e admissão de segurança do pod (PSA)

Em resposta à descontinuação do PSP e à necessidade contínua de controlar a segurança do pod out-of-the-box, com uma solução Kubernetes integrada, o Kubernetes Auth Special Interest Group criou o Pod Security Standards (PSS) e o Pod Security Admission (PSA). O esforço do PSA inclui um projeto de webhook do controlador de admissão que implementa os controles definidos no PSS. Essa abordagem de controlador de admissão é semelhante à usada nas soluções PAC.

De acordo com a documentação do Kubernetes, o PSS “`define três políticas diferentes para cobrir amplamente o espectro de segurança. Essas políticas são cumulativas e variam de altamente permissivas a altamente restritivas. `”

Essas políticas são definidas como:

  • Privilegiado: política irrestrita (não segura), fornecendo o nível mais amplo possível de permissões. Essa política permite escalonamentos de privilégios conhecidos. É a ausência de uma política. Isso é bom para aplicativos como agentes de registro CNIs, drivers de armazenamento e outros aplicativos de todo o sistema que precisam de acesso privilegiado.

  • Linha de base: política minimamente restritiva que evita escalonamentos de privilégios conhecidos. Permite a configuração padrão (minimamente especificada) do pod. A política básica proíbe o uso de HostNetwork, HostPid, HostPC, HostPath, HostPort, a incapacidade de adicionar recursos Linux, além de várias outras restrições.

  • Restrito: política altamente restrita, seguindo as melhores práticas atuais de fortalecimento de Pod. Essa política é herdada da linha de base e adiciona mais restrições, como a incapacidade de ser executada como raiz ou como grupo-raiz. Políticas restritas podem afetar a capacidade de funcionamento de um aplicativo. Eles são voltados principalmente para a execução de aplicativos essenciais de segurança.

Essas políticas definem perfis para execução de pods, organizados em três níveis de acesso privilegiado versus acesso restrito.

Para implementar os controles definidos pelo PSS, o PSA opera em três modos:

  • impor: violações da política farão com que o pod seja rejeitado.

  • auditoria: as violações da política acionarão a adição de uma anotação de auditoria ao evento registrado no registro de auditoria, mas são permitidas de outra forma.

  • aviso: as violações da política acionarão um aviso voltado para o usuário, mas, de outra forma, são permitidas.

Esses modos e os níveis de perfil (restrição) são configurados no nível do Kubernetes Namespace, usando rótulos, conforme mostrado no exemplo abaixo.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/enforce: restricted

Quando usados de forma independente, esses modos operacionais têm respostas diferentes que resultam em experiências de usuário diferentes. O modo de aplicação impedirá a criação de pods se os respectivos PodSpecs violarem o nível de restrição configurado. No entanto, nesse modo, objetos Kubernetes que não sejam de pod que criam pods, como Deployments, não serão impedidos de serem aplicados ao cluster, mesmo que o PodSpec nele viole o PSS aplicado. Nesse caso, a implantação será aplicada, enquanto os pods serão impedidos de serem aplicados.

Essa é uma experiência difícil para o usuário, pois não há indicação imediata de que o objeto de implantação aplicado com sucesso oculte a falha na criação do pod. Os PodSpecs ofensivos não criarão pods. A inspeção do recurso de implantação com kubectl get deploy <DEPLOYMENT_NAME> -oyaml exibirá a mensagem do (s) .status.conditions elemento (s) do pod (s) com falha, conforme mostrado abaixo.

...
status:
  conditions:
    - lastTransitionTime: "2022-01-20T01:02:08Z"
      lastUpdateTime: "2022-01-20T01:02:08Z"
      message: 'pods "test-688f68dc87-tw587" is forbidden: violates PodSecurity "restricted:latest":
        allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false),
        unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]),
        runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true),
        seccompProfile (pod or container "test" must set securityContext.seccompProfile.type
        to "RuntimeDefault" or "Localhost")'
      reason: FailedCreate
      status: "True"
      type: ReplicaFailure
...

Nos modos de auditoria e aviso, as restrições de pods não impedem que pods violadores sejam criados e iniciados. No entanto, nesses modos, as anotações de auditoria nos eventos do log de auditoria do servidor de API e os avisos para clientes do servidor de API, como kubectl, são acionados, respectivamente, quando pods, assim como objetos que criam pods, contêm podSpecs com violações. Uma mensagem de kubectl aviso é exibida abaixo.

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "test" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
deployment.apps/test created

Os modos de auditoria e aviso do PSA são úteis ao introduzir o PSS sem afetar negativamente as operações do cluster.

Os modos operacionais do PSA não são mutuamente exclusivos e podem ser usados de forma cumulativa. Conforme mostrado abaixo, os vários modos podem ser configurados em um único namespace.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

No exemplo acima, os avisos fáceis de usar e as anotações de auditoria são fornecidos ao aplicar Deployments, enquanto a aplicação de violações também é fornecida no nível do pod. Na verdade, vários rótulos de PSA podem usar diferentes níveis de perfil, conforme mostrado abaixo.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/warn: restricted

No exemplo acima, o PSA é configurado para permitir a criação de todos os pods que satisfaçam o nível básico do perfil e, em seguida, avisar sobre pods (e objetos que criam pods) que violam o nível de perfil restrito. Essa é uma abordagem útil para determinar os possíveis impactos ao mudar da linha de base para perfis restritos.

Pods existentes

Se um namespace com pods existentes for modificado para usar um perfil PSS mais restritivo, os modos de auditoria e aviso produzirão mensagens apropriadas; no entanto, o modo de aplicação não excluirá os pods. As mensagens de aviso são vistas abaixo.

Warning: existing pods in namespace "policy-test" violate the new PodSecurity enforce level "restricted:latest"
Warning: test-688f68dc87-htm8x: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile
namespace/policy-test configured

Isenções

O PSA usa isenções para excluir a aplicação de violações contra grupos que, de outra forma, teriam sido aplicadas. Essas isenções estão listadas abaixo.

  • Nomes de usuário: solicitações de usuários com um nome de usuário autenticado (ou personificado) isento são ignoradas.

  • RuntimeClassNames: pods e recursos de carga de trabalho que especificam um nome de classe de tempo de execução isento são ignorados.

  • Namespaces: pods e recursos de carga de trabalho em um namespace isento são ignorados.

Essas isenções são aplicadas estaticamente na configuração do controlador de admissão do PSA como parte da configuração do servidor da API.

Na implementação do Validating Webhook, as isenções podem ser configuradas em um ConfigMaprecurso do Kubernetes que é montado como um volume no contêiner. pod-security-webhook

apiVersion: v1
kind: ConfigMap
metadata:
  name: pod-security-webhook
  namespace: pod-security-webhook
data:
  podsecurityconfiguration.yaml: |
    apiVersion: pod-security.admission.config.k8s.io/v1
    kind: PodSecurityConfiguration
    defaults:
      enforce: "restricted"
      enforce-version: "latest"
      audit: "restricted"
      audit-version: "latest"
      warn: "restricted"
      warn-version: "latest"
    exemptions:
      # Array of authenticated usernames to exempt.
      usernames: []
      # Array of runtime class names to exempt.
      runtimeClasses: []
      # Array of namespaces to exempt.
      namespaces: ["kube-system","policy-test1"]

Conforme visto no ConfigMap YAML acima, o nível PSS padrão em todo o cluster foi definido como restrito para todos os modos de PSA, auditoria, aplicação e aviso. Isso afeta todos os namespaces, exceto aqueles isentos:. namespaces: ["kube-system","policy-test1"] Além disso, no ValidatingWebhookConfigurationrecurso, visto abaixo, o pod-security-webhooknamespace também está isento do PSS configurado.

...
webhooks:
  # Audit annotations will be prefixed with this name
  - name: "pod-security-webhook.kubernetes.io"
    # Fail-closed admission webhooks can present operational challenges.
    # You may want to consider using a failure policy of Ignore, but should
    # consider the security tradeoffs.
    failurePolicy: Fail
    namespaceSelector:
      # Exempt the webhook itself to avoid a circular dependency.
      matchExpressions:
        - key: kubernetes.io/metadata.name
          operator: NotIn
          values: ["pod-security-webhook"]
...
Importante

O Pod Security Admissions passou para estável no Kubernetes v1.25. Se você quiser usar o recurso Pod Security Admission antes de ser ativado por padrão, precisará instalar o controlador de admissão dinâmico (webhook mutante). As instruções para instalar e configurar o webhook podem ser encontradas aqui.

Escolhendo entre policy-as-code os padrões de segurança do Pod

Os Pod Security Standards (PSS) foram desenvolvidos para substituir a Política de Segurança do Pod (PSP), fornecendo uma solução integrada ao Kubernetes e que não exigia soluções do ecossistema Kubernetes. Dito isso, as soluções policy-as-code (PAC) são consideravelmente mais flexíveis.

A lista de prós e contras a seguir foi projetada para ajudá-lo a tomar uma decisão mais informada sobre sua solução de segurança de pod.

Policy-as-code (em comparação com os padrões de segurança do Pod)

Prós:

  • Mais flexível e mais granular (até os atributos dos recursos, se necessário)

  • Não é apenas focado em cápsulas, pode ser usado contra diferentes recursos e ações

  • Não é aplicado apenas no nível do namespace

  • Mais maduro do que os padrões de segurança do Pod

  • As decisões podem ser baseadas em qualquer coisa na carga de solicitação do servidor da API, bem como nos recursos de cluster existentes e nos dados externos (dependendo da solução)

  • Suporta solicitações mutantes do servidor de API antes da validação (depende da solução)

  • Pode gerar políticas complementares e recursos do Kubernetes (depende da solução) - A partir das políticas de pod, o Kyverno pode gerar políticas automaticamente para controladores de nível superior, como implantações. O Kyverno também pode gerar recursos adicionais do Kubernetes “`quando um novo recurso é criado ou quando a fonte é atualizada`” usando Generate Rules.)

  • Pode ser usado para mudar para a esquerda, para os pipelines do CICD, antes de fazer chamadas para o servidor da API Kubernetes (dependente da solução)

  • Pode ser usado para implementar comportamentos que não estão necessariamente relacionados à segurança, como melhores práticas, padrões organizacionais etc.

  • Pode ser usado em casos de uso que não sejam do Kubernetes (depende da solução)

  • Devido à flexibilidade, a experiência do usuário pode ser ajustada às necessidades dos usuários

Contras:

  • Não incorporado ao Kubernetes

  • Mais complexo de aprender, configurar e oferecer suporte

  • A criação de políticas pode exigir novas skills/languages/capabilities

Admissão de segurança do Pod (em comparação com policy-as-code)

Prós:

  • Integrado ao Kubernetes

  • Mais simples de configurar

  • Sem novos idiomas para usar ou políticas para criar

  • Se o nível de admissão padrão do cluster estiver configurado como privilegiado, os rótulos de namespace poderão ser usados para incluir namespaces nos perfis de segurança do pod.

Contras:

  • Não é tão flexível ou granular quanto policy-as-code

  • Apenas 3 níveis de restrições

  • Focado principalmente em cápsulas

Resumo

Se você atualmente não tem uma solução de segurança de pod, além do PSP, e sua postura de segurança de pod necessária se encaixa no modelo definido nos Padrões de Segurança de Pod (PSS), um caminho mais fácil pode ser adotar o PSS, em vez de uma solução. policy-as-code No entanto, se a postura de segurança do seu pod não se encaixa no modelo PSS, ou se você pretende adicionar controles adicionais, além dos definidos pelo PSS, uma policy-as-code solução pareceria mais adequada.

Recomendações

Use vários modos de admissão de segurança do Pod (PSA) para uma melhor experiência do usuário

Conforme mencionado anteriormente, o modo PSA enforce impede que pods com violações de PSS sejam aplicados, mas não interrompe controladores de nível superior, como Deployments. Na verdade, a implantação será aplicada com sucesso sem qualquer indicação de que os pods não foram aplicados. Embora você possa usar o kubectl para inspecionar o objeto de implantação e descobrir a mensagem de pods com falha do PSA, a experiência do usuário poderia ser melhor. Para melhorar a experiência do usuário, vários modos de PSA (auditoria, aplicação, aviso) devem ser usados.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

No exemplo acima, com o modo de imposição definido, quando um manifesto de implantação com violações de PSS no respectivo PodSpec tentar ser aplicado ao servidor da API Kubernetes, a implantação será aplicada com sucesso, mas os pods não. E, como os modos de auditoria e aviso também estão habilitados, o cliente do servidor da API receberá uma mensagem de aviso e o evento do log de auditoria do servidor da API também será anotado com uma mensagem.

Restrinja os contêineres que podem ser executados como privilegiados

Conforme mencionado, os contêineres que são executados com privilégios herdam todos os recursos do Linux atribuídos ao root no host. Raramente os contêineres precisam desses tipos de privilégios para funcionar adequadamente. Há vários métodos que podem ser usados para restringir as permissões e os recursos dos contêineres.

Importante

O Fargate é um tipo de lançamento que permite que você execute contêineres “sem servidor”, onde os contêineres de um pod são executados na infraestrutura gerenciada pela AWS. Com o Fargate, você não pode executar um contêiner privilegiado nem configurar seu pod para usar HostNetwork ou HostPort.

Não execute processos em contêineres como root

Todos os contêineres são executados como root por padrão. Isso pode ser problemático se um invasor conseguir explorar uma vulnerabilidade no aplicativo e obter acesso ao shell ao contêiner em execução. Você pode mitigar esse risco de várias maneiras. Primeiro, removendo a casca da imagem do contêiner. Segundo, adicionar a diretiva USER ao seu Dockerfile ou executar os contêineres no pod como um usuário não root. O Kubernetes PodSpec inclui um conjunto de campos, emspec.securityContext, que permite especificar o and/or grupo de usuários sob o qual executar seu aplicativo. Esses campos são runAsUser e runAsGroup respectivamente.

Para impor o uso do e de seus elementos associados no spec.securityContext Kubernetes, o PodSpec policy-as-code ou os Padrões de Segurança do Pod podem ser adicionados aos clusters. Essas soluções permitem que você escreva e/ou use políticas ou perfis que possam validar cargas de solicitação de entrada do servidor da API Kubernetes, antes que elas persistam no etcd. Além disso, policy-as-code as soluções podem alterar as solicitações recebidas e, em alguns casos, gerar novas solicitações.

Nunca execute o Docker no Docker nem monte o soquete no contêiner

Embora isso permita que você crie build/run imagens em contêineres do Docker, você está basicamente cedendo o controle total do nó ao processo em execução no contêiner. Se você precisar criar imagens de contêiner no Kubernetes, use Kaniko, buildah ou um serviço de compilação semelhante. CodeBuild

nota

Os clusters Kubernetes usados para processamento de CICD, como a criação de imagens de contêineres, devem ser isolados dos clusters que executam cargas de trabalho mais generalizadas.

Restrinja o uso do HostPath ou, se o HostPath for necessário, restrinja quais prefixos podem ser usados e configure o volume como somente para leitura

hostPathé um volume que monta um diretório do host diretamente no contêiner. Raramente os pods precisarão desse tipo de acesso, mas se precisarem, você precisa estar ciente dos riscos. Por padrão, os pods executados como root terão acesso de gravação ao sistema de arquivos exposto pelo HostPath. Isso pode permitir que um invasor modifique as configurações do kubelet, crie links simbólicos para diretórios ou arquivos não expostos diretamente pelo HostPath, por exemplo, /etc/shadow, instale chaves ssh, leia segredos montados no host e outras coisas maliciosas. Para mitigar os riscos do HostPath, configure o spec.containers.volumeMounts comoreadOnly, por exemplo:

volumeMounts:
- name: hostPath-volume
    readOnly: true
    mountPath: /host-path

Você também deve usar policy-as-code soluções para restringir os diretórios que podem ser usados por hostPath volumes ou impedir totalmente o hostPath uso. Você pode usar a linha de base dos padrões de segurança do Pod ou as políticas restritas para evitar o uso dehostPath.

Para obter mais informações sobre os perigos da escalação privilegiada, leia o blog Bad Pods: Kubernetes Pod Privilege Escalation de Seth Art.

Defina solicitações e limites para cada contêiner para evitar contenção de recursos e ataques de DoS

Um pod sem solicitações ou limites pode, teoricamente, consumir todos os recursos disponíveis em um host. À medida que pods adicionais são programados em um nó, o nó pode sofrer pressão de CPU ou memória, o que pode fazer com que o Kubelet encerre ou expulse pods do nó. Embora você não possa evitar que isso aconteça completamente, definir solicitações e limites ajudará a minimizar a contenção de recursos e mitigar o risco de aplicativos mal escritos que consomem uma quantidade excessiva de recursos.

O podSpec permite que você especifique solicitações e limites para CPU e memória. A CPU é considerada um recurso compressível porque pode ter excesso de assinaturas. A memória é incompressível, ou seja, não pode ser compartilhada entre vários contêineres.

Ao especificar solicitações de CPU ou memória, você está basicamente designando a quantidade de memória que os contêineres têm a garantia de receber. O Kubernetes agrega as solicitações de todos os contêineres em um pod para determinar em qual nó programar o pod. Se um contêiner exceder a quantidade de memória solicitada, ele poderá estar sujeito ao encerramento se houver pressão de memória no nó.

Os limites são a quantidade máxima de recursos de CPU e memória que um contêiner pode consumir e correspondem diretamente ao memory.limit_in_bytes valor do cgroup criado para o contêiner. Um contêiner que exceda o limite de memória será eliminado pelo OOM. Se um contêiner exceder seu limite de CPU, ele será acelerado.

nota

Ao usar o contêinerresources.limits, é altamente recomendável que o uso dos recursos do contêiner (também conhecido como Resource Footprints) seja orientado por dados e preciso, com base em testes de carga. Sem uma pegada de recursos precisa e confiável, o contêiner resources.limits pode ser acolchoado. Por exemplo, resources.limits.memory pode ser preenchido de 20 a 30% a mais do que os máximos observáveis, para considerar possíveis imprecisões no limite de recursos de memória.

O Kubernetes usa três classes de Qualidade de Serviço (QoS) para priorizar as cargas de trabalho em execução em um nó. Isso inclui:

  • garantidos

  • estourável

  • melhor esforço

Se os limites e as solicitações não forem definidos, o pod será configurado como melhor esforço (prioridade mais baixa). As cápsulas de melhor esforço são as primeiras a serem mortas quando não há memória suficiente. Se os limites forem definidos em todos os contêineres dentro do pod, ou se as solicitações e os limites forem definidos com os mesmos valores e não forem iguais a 0, o pod será configurado como garantido (prioridade mais alta). Os pods garantidos não serão eliminados a menos que excedam os limites de memória configurados. Se os limites e as solicitações estiverem configurados com valores diferentes e não forem iguais a 0, ou se um contêiner dentro do pod definir limites e os outros não tiverem ou tiverem limites definidos para recursos diferentes, os pods serão configurados como intermitentes (prioridade média). Esses pods têm algumas garantias de recursos, mas podem ser eliminados quando excedem a memória solicitada.

Importante

As solicitações não afetam o memory_limit_in_bytes valor do cgroup do contêiner; o limite do cgroup é definido para a quantidade de memória disponível no host. No entanto, definir o valor da solicitação muito baixo pode fazer com que o pod seja direcionado para o encerramento pelo kubelet se o nó sofrer pressão de memória.

Classe Prioridade Condição Condição de morte

Garantido

highest

limite = solicitação! = 0

Exceda apenas os limites de memória

Performance expansível

medium

limite! = solicitação! = 0

Pode ser eliminado se exceder a memória solicitada

Melhor esforço

lowest

limite e solicitação não definidos

O primeiro a ser morto quando não há memória suficiente

Para obter informações adicionais sobre QoS de recursos, consulte a documentação do Kubernetes.

Você pode forçar o uso de solicitações e limites definindo uma cota de recursos em um namespace ou criando um intervalo limite. Uma cota de recursos permite que você especifique a quantidade total de recursos, por exemplo, CPU e RAM, alocados para um namespace. Quando aplicado a um namespace, ele força você a especificar solicitações e limites para todos os contêineres implantados nesse namespace. Por outro lado, os intervalos de limite oferecem um controle mais granular da alocação de recursos. Com intervalos de limite, você pode usar min/max recursos de CPU e memória por pod ou por contêiner em um namespace. Você também pode usá-los para definir valores de solicitação/limite padrão, caso nenhum seja fornecido.

Policy-as-code as soluções podem ser usadas para impor solicitações e limites. ou até mesmo para criar cotas de recursos e intervalos de limite quando os namespaces são criados.

Não permita escalonamento privilegiado

O escalonamento privilegiado permite que um processo altere o contexto de segurança sob o qual está sendo executado. O Sudo é um bom exemplo disso, assim como os binários com o bit SUID ou SGID. O escalonamento privilegiado é basicamente uma forma de os usuários executarem um arquivo com as permissões de outro usuário ou grupo. Você pode impedir que um contêiner use o escalonamento privilegiado policy-as-code implementando uma política mutante definida allowPrivilegeEscalation como false ou configurando o. securityContext.allowPrivilegeEscalation podSpec Policy-as-code as políticas também podem ser usadas para impedir que as solicitações do servidor de API sejam bem-sucedidas se configurações incorretas forem detectadas. Os padrões de segurança de pods também podem ser usados para impedir que os pods usem o escalonamento de privilégios.

Desativar montagens de ServiceAccount tokens

Para pods que não precisam acessar a API Kubernetes, você pode desativar a montagem automática de um ServiceAccount token em uma especificação de pod ou para todos os pods que usam um determinado token. ServiceAccount

apiVersion: v1
kind: Pod
metadata:
  name: pod-no-automount
spec:
  automountServiceAccountToken: false
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-no-automount
automountServiceAccountToken: false

Desativar descoberta de serviços

Para pods que não precisam pesquisar ou chamar serviços no cluster, você pode reduzir a quantidade de informações fornecidas a um pod. Você pode definir a política de DNS do pod para não usar CoreDNS e não expor serviços no namespace do pod como variáveis de ambiente. Consulte a documentação do Kubernetes sobre variáveis de ambiente para obter mais informações sobre links de serviços. O valor padrão da política de DNS de um pod é "ClusterFirst", que usa DNS no cluster, enquanto o valor não padrão “Default” usa a resolução DNS do nó subjacente. Consulte a documentação do Kubernetes sobre a política de DNS do Pod para obter mais informações.

apiVersion: v1
kind: Pod
metadata:
  name: pod-no-service-info
spec:
    dnsPolicy: Default # "Default" is not the true default value
    enableServiceLinks: false

Configure suas imagens com o sistema de arquivos raiz somente para leitura

Configurar suas imagens com um sistema de arquivos raiz somente para leitura impede que um invasor sobrescreva um binário no sistema de arquivos que seu aplicativo usa. Se seu aplicativo precisar gravar no sistema de arquivos, considere gravar em um diretório temporário ou anexar e montar um volume. Você pode aplicar isso configurando os pods da SecurityContext seguinte forma:

...
securityContext:
  readOnlyRootFilesystem: true
...

Policy-as-code e os Padrões de Segurança do Pod podem ser usados para impor esse comportamento.

De acordo com o Windows, os contêineres no Kubernetes securityContext.readOnlyRootFilesystem não podem ser configurados true para um contêiner em execução no Windows, pois o acesso de gravação é necessário para que os processos de registro e do sistema sejam executados dentro do contêiner.

Ferramentas e recursos