O campo streamingConnectionIdleTimeout de uma configuração do Kubelet especifica a quantidade máxima de tempo que uma conexão de streaming fica inativa antes que a conexão seja fechada automaticamente. Definir tempos limite ociosos protege contra ataques de negação de serviço e a falta de conexões. Definir o valor do campo como 0 desabilita o tempo limite ocioso.

Exemplo 1: A configuração do Kubelet a seguir desabilita o tempo limite da conexão de streaming definindo o campo streamingConnectionIdleTimeout como 0.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
streamingConnectionIdleTimeout: 0

Um servidor da API Kubernetes pode autorizar uma solicitação usando um dos vários modos de autorização. O servidor API não executa nenhuma verificação de autorização no modo AlwaysAllow porque permite todas as solicitações.

Exemplo 1: A configuração a seguir inicia um servidor da API Kubernetes tendo AlwaysAllow como um dos modos de autorização.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --authorization-mode=...,AlwaysAllow,...
    ...

O gerenciador do controlador Kubernetes começa sem o sinalizador --root-ca-file que especifica um arquivo raiz de autoridade de certificação (CA). Como resultado, o gerenciador do controlador Kubernetes não publica um certificado CA raiz correspondente nos pods. Sem o certificado de raiz CA, os pods não podem verificar o certificado de serviço do servidor de API antes de estabelecer conexões. Isso deixa o aplicativo vulnerável a um ataque MITM (man-in-the-middle).

Exemplo 1: A configuração a seguir inicia um gerenciador de controlador Kubernetes sem o sinalizador --root-ca-file.

...
kind: Pod
...
spec:
  containers:
    - command:
      - kube-controller-manager
    image: k8s.gcr.io/kube-controller-manager:v1.9.7
    imagePullPolicy: IfNotPresent
      ...

Um controlador Kubernetes inicia a coleta de lixo para recuperar recursos ocupados por pods encerrados quando o número deles excede um limite. Embora a coleta de lixo excessiva prejudique o desempenho, o limite padrão de 12.500 é muito alto para um cluster típico. Antes que qualquer coleta de lixo ocorra, o cluster pode ficar sem recursos e se tornar instável.

Exemplo 1: A configuração a seguir inicia um gerenciador de controlador Kubernetes sem especificar um limite.

...
kind: Pod
...
spec:
  containers:
    - command:
      - kube-controller-manager
    image: example.domain/kube-controller-manager:v1.9.7
    imagePullPolicy: IfNotPresent
...

Um Kubelet autoriza uma solicitação usando o modo AlwaysAllow ou o modo Webhook. Um modo de autorização não especificado é padronizado como AlwaysAllow . O Kubelet não realiza nenhuma verificação de autorização no modo AlwaysAllow porque permite todas as solicitações. Como os Kubelets são os principais agentes do Kubernetes para gerenciar a carga de trabalho de uma máquina de trabalho, os invasores podem usar solicitações não controladas para obter acesso a APIs de serviço com proteção insuficiente e sensíveis à segurança.

Exemplo 1: O Kubelet não executa nenhuma verificação de autorização porque o modo de autorização está definido como AlwaysAllow .

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authorization:
  mode: AlwaysAllow

Os Kubelets podem autenticar clientes, mas o pacote da Autoridade de Certificação (CA) é usado para verificar se o certificado do cliente não está definido na Configuração do Kubelet. Como os Kubelets são os principais agentes do Kubernetes usados para gerenciar uma carga de trabalho da máquina do trabalhador, os invasores podem usar solicitações anônimas para obter acesso a APIs de serviço com proteção insuficiente e sensíveis à segurança.

Exemplo 1: A configuração do Kubelet a seguir não contém o campo clientCAFile que especifica o pacote de CA usado para verificar certificados do cliente.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration

Por padrão, um servidor da API Kubernetes não se autentica no Kubelets ao enviar solicitações. Os Kubelets, que fornecem acesso a uma ampla variedade de recursos, não podem verificar a autenticidade dessas solicitações.

Exemplo 1: O comando a seguir inicia um servidor da API Kubernetes sem especificar um certificado de cliente e a chave privada correspondente com o sinalizador --kubelet-client-certificate e o sinalizador --kubelet-client-key, respectivamente, para habilitar a autenticação baseada em certificado para Kubelets.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --audit-log-maxage=50
    - --audit-log-maxbackup=20
    - --audit-log-maxsize=200
    image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
    ...

Um servidor da API do Kubernetes envia instruções ao Kubelets para criar carga de trabalho, consulta o status dos recursos gerenciados pelo Kubelet e fornece serviços opcionais de encaminhamento de porta aos Kubelets. Por padrão, o servidor API não verifica o certificado de serviço do Kubelet antes de estabelecer a conexão. Essa conexão, portanto, está suscetível a um ataque MITM (man-in-the-middle).

Exemplo 1: O comando a seguir inicia um servidor da API Kubernetes sem especificar um pacote de certificado raiz para verificar o certificado de serviço do Kubelet com o sinalizador --kubelet-certificate-authority.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --audit-log-maxage=50
    - --audit-log-maxbackup=20
    - --audit-log-maxsize=200
  image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
    ...

Um servidor da API Kubernetes pode autorizar uma solicitação usando um dos vários modos de autorização. A autorização Node é um modo de autorização de propósito especial que autoriza especificamente solicitações de API feitas por Kubelets. Isso garante que os Kubelets tenham o conjunto mínimo de permissões necessárias para operar corretamente.

Exemplo 1: A configuração a seguir inicia um servidor da API Kubernetes sem o modo de autorização Node.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --authorization-mode=RBAC,Webhook
    ...

Sempre habilite o controlador de admissão NodeRestriction para um servidor de API do Kubernetes. O controlador de admissão NodeRestriction limita cada Kubelet a modificar seus objetos Node e Pod, bem como negar acesso a objetos confidenciais do sistema. Isso impede que qualquer nó comprometido obtenha privilégios em outros nós de um cluster do Kubernetes.

Exemplo 1: A definição de Pod a seguir inicia um servidor da API Kubernetes sem habilitar o controlador de admissão NodeRestriction.

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --enable-admission-plugins=PodSecurityPolicy
    ...

A falta de um controlador de admissão PodSecurityPolicy é indicativo de controles de segurança fracos, a menos que haja uma ferramenta alternativa de aplicação de políticas para Kubernetes, como K-Rail, Kyverno, OPA/Gatekeeper. O controlador de admissão PodSecurityPolicy impõe políticas de segurança de pod que especificam atributos de pod relacionados à segurança permitidos em um cluster. Por exemplo, usando PodSecurityPolicy, você pode proibir contêineres privilegiados e desabilitar o escalonamento de privilégios por padrão sempre que um Pod é criado.

Exemplo 1: A definição de Pod a seguir inicia um servidor da API Kubernetes sem habilitar o controlador de admissão PodSecurityPolicy.

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --enable-admission-plugins=NodeRestriction
    ...

Um servidor da API Kubernetes pode autorizar uma solicitação usando um dos vários modos de autorização. O controle de acesso baseado em função (RBAC ) controla o acesso a recursos de computador ou rede com base nas funções de usuários individuais em uma organização. O RBAC é o modo de autorização mais seguro.

Exemplo 1: A configuração a seguir inicia um servidor da API Kubernetes sem o modo de autorização RBAC.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --authorization-mode=Node,Webhook
    ...

É uma boa prática definir permissões de forma granular que aderem ao Princípio de Privilégios Mínimos. Um contexto de segurança do Kubernetes define privilégios e configurações de controle de acesso para um Contêiner ou Pod. Um Contêiner não terá contexto de segurança se não houver essa configuração no nível do Pod e do Contêiner.

Exemplo 1: A configuração a seguir define um Pod sem qualquer contexto de segurança porque não há o campo securityContext.

apiVersion: v1
kind: Pod
...
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP

O controlador de admissão SecurityContextDeny impede que os Pods definam determinados campos do SecurityContext que permitem o escalonamento de privilégios em um cluster do Kubernetes. A menos que haja uma ferramenta alternativa de aplicação de políticas para o Kubernetes, como políticas de segurança de Pods apropriadas, o controlador de admissão SecurityContextDeny deve ser habilitado.

Exemplo 1: A definição de Pod a seguir inicia um servidor de API do Kubernetes sem habilitar o controlador de admissão SecurityContextDeny.

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --enable-admission-plugins=NodeRestriction
    ...

Um servidor de API do Kubernetes pode autenticar solicitações de API por tokens de conta de serviço. Esses tokens são gerados e assinados pelo controlador de token do Kubernetes. Use o sinalizador --service-account-private-key-file para especificar a chave de assinatura do token.

Exemplo 1: A configuração a seguir inicia um gerenciador de controlador Kubernetes sem o sinalizador --service-account-private-key-file.

apiVersion: v1
kind: Pod
...
spec:
  containers:
    - command:
        - kube-controller-manager
    image: k8s.gcr.io/kube-controller-manager:v1.9.7
...

O Kubernetes distingue entre o conceito de uma conta de usuário e uma conta de serviço, que é para um processo ser executado em um pod. O controlador de admissão ServiceAccount automatiza o gerenciamento da conta de serviço. Alguns benefícios do controlador de admissão ServiceAccount são para mitigar a exfiltração de token de acesso com rotação automatizada de credenciais e eliminar a necessidade de persistir segredos no armazenamento. O controlador de admissão ServiceAccount está habilitado por padrão, mas foi deliberadamente desabilitado.

Exemplo 1: A definição de Pod a seguir inicia um servidor de API do Kubernetes e desabilita o controlador de admissão ServiceAccount.

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --disable-admission-plugins=ServiceAccount,PodNodeSelector
    ...

A exclusão do namespace Kubernetes remove todos os objetos desse namespace, incluindo pods e serviços. O controlador de admissão NamespaceLifecycle mantém a integridade dos sistemas Kubernetes de duas maneiras. Primeiro, ele evita que objetos sejam criados em namespaces inexistentes ou em namespaces que estão sendo encerrados. Em segundo lugar, evita que os namespaces reservados do sistema, que contêm serviços essenciais do Kubernetes, sejam excluídos.

O controlador de admissão NamespaceLifecycle é ativado por padrão, mas o comando para iniciar o servidor da API Kubernetes o desativou com o sinalizador --disable-admission-plugin.

Exemplo 1: A configuração a seguir inicia um servidor da API Kubernetes. A presença do NamespaceLifecycle incluído no sinalizador --disable-admission-plugins desativa o controlador de admissão NamespaceLifecycle.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --disable-admission-plugins=...,NamespaceLifecycle,...
    ...

O Kubernetes mantém dados confidenciais em um cluster etcd. Portanto, cada instância do etcd deve aceitar apenas conexões de pares autenticados e autorizados e rejeitar quaisquer pares que usem certificados autoassinados para conexões TLS.

Exemplo 1: A configuração a seguir inicia uma instância etcd e define o sinalizador --peer-auto-tls como true. Como resultado, a instância etcd usa certificados autoassinados para conexões TLS com pares.

	...
	spec:
	containers:
	- command:
	...
	- etcd
	...
	- --peer-auto-tls=true
	...

Um recurso do Kubernetes permite que um pod execute ações root sem dar acesso root pleno. A capacidade CAP_SYS_ADMIN concede a permissão para realizar a maior variedade possível de operações de administração do sistema em um pod.

Exemplo 1: O seguinte manifesto do Kubernetes adiciona a capacidade CAP_SYS_ADMIN para um contêiner em um pod.

...
kind: Pod
...
spec:
  containers:
...
    securityContext:
      capabilities:
        add:
        - CAP_SYS_ADMIN
        - SYS_TIME
        ...

Por padrão, um contêiner Kubernetes não tem acesso a todos os dispositivos no host. O campo privileged permite ao contêiner quase todos os mesmos privilégios de outros processos em execução no host. Isso expande a superfície de ataque e viola o princípio de execução de imagens com o mínimo de privilégios.

Exemplo 1: O pod é executado em um modo privilegiado, definindo privileged: true.

...
kind: Pod
...
spec:
  containers:
    - name: ...
      image: ...
      securityContext:
         privileged: true
...