O acesso descontrolado a recursos críticos ou confidenciais pode afetar significativamente uma organização de várias maneiras, incluindo a divulgação ou adulteração de dados críticos.

O acesso descontrolado a recursos críticos ou confidenciais pode afetar significativamente uma organização de várias maneiras, incluindo a divulgação ou adulteração de dados críticos.

O acesso descontrolado a recursos críticos ou confidenciais pode afetar significativamente uma organização de várias maneiras, incluindo a divulgação ou adulteração de dados críticos.

O acesso descontrolado a recursos críticos ou confidenciais pode afetar significativamente uma organização de várias maneiras, incluindo a divulgação ou adulteração de dados críticos.

O acesso descontrolado a recursos críticos ou confidenciais pode afetar significativamente uma organização de várias maneiras, incluindo a divulgação ou adulteração de dados críticos.

O Kubernetes mantém dados confidenciais em um cluster etcd. Uma instância etcd aceita conexões de clientes sem certificados assinados por autoridades de certificação confiáveis porque o comando para iniciar o etcd com o sinalizador --client-cert-auth está definida como false .

Exemplo 1: A configuração a seguir inicia uma instância etcd e define o sinalizador --client-cert-auth como false.

...
spec:
  containers:
    - command:
  ...
      - etcd
  ...
      --client-cert-auth=false
  ...

O Kubernetes mantém dados confidenciais em um cluster etcd. Cada instância etcd deve servir clientes em conexões do TLS, mas os sinalizadores de linha de comando para configurar as conexões do TLS estão ausentes.

Exemplo 1: A configuração a seguir inicia uma instância etcd sem especificar os sinalizadores --cert-file e --key-file para configurar conexões do TLS.

apiVersion: v1
spec:
  containers:
    - command:
      - etcd
      - --data-dir=/var/lib/etcd
    image: k8s.gcr.io/etcd:3.4.3-0
  ...

O Kubernetes mantém dados confidenciais em um cluster etcd. Cada instância etcd em um cluster deve sempre se comunicar com pares por meio de uma conexão do TLS, mas os sinalizadores de linha de comando para configurar a conexão do TLS estão ausentes.

Exemplo 1: A configuração a seguir inicia uma instância etcd sem especificar os sinalizadores --peer-cert-file e --peer-key-file para configurar uma conexão do TLS.

apiVersion: v1
spec:
  containers:
    - command:
      - etcd
      - --data-dir=/var/lib/etcd
    image: k8s.gcr.io/etcd:3.4.3-0
...

As conexões de um servidor da API Kubernetes para Kubelets geralmente carregam dados confidenciais, como segredos e comandos. Por padrão, as conexões entre o servidor API e os Kubelets são protegidas em trânsito por meio do Transport Layer Security (TLS). Se o sinalizador --kubelet-https está definido como false , a comunicação segura está desativada.

Exemplo 1: A configuração a seguir desativa a comunicação segura entre o servidor API e os Kubelets porque o servidor API inicia com o sinalizador --kubelet-https definido como false.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --kublet-https=false
    - --authorization-mode=RBAC
    image: example.domain/kube-apiserver-amd64:v1.6.0
    ...

Canais de comunicação de dados protegidos de forma insuficiente podem colocar dados organizacionais críticos em risco de roubo, adulteração ou divulgação.

Os arquivos de log devem ser mantidos por tempo suficiente para facilitar a análise pós-incidente e a detecção de ameaças, bem como para atender aos requisitos de conformidade. O sinalizador --audit-log-maxage define o número máximo de dias para reter arquivos de log de auditoria antigos. Ou a sinalização não está presente no comando para iniciar um servidor da API Kubernetes ou o período de retenção está definido com menos de 30 dias.

Exemplo 1: O comando a seguir inicia um servidor da API Kubernetes e define o sinalizador --audit-log-maxage para 2 (2 dias), que é muito curto.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --audit-log-maxage=2
    ...

O servidor da API Kubernetes automaticamente faz a rotação dos arquivos de log. Para facilitar a análise pós-incidente e a detecção de ameaças, bem como para atender aos requisitos de conformidade, você deve reter uma quantidade suficiente de dados de log. O sinalizador --audit-log-maxbackup define o número máximo de arquivos de log a serem retidos. Ou esse sinalizador não está presente no comando para iniciar um servidor da API Kubernetes ou o número máximo de arquivos de log a serem retidos é menor do que 10.

Exemplo 1: O comando a seguir inicia um servidor da API Kubernetes e define o sinalizador --audit-log-maxbackup como 2, que retém insuficientemente apenas dois arquivos de log.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --audit-log-maxbackup=2
    ...

O servidor da API Kubernetes automaticamente faz a rotação dos arquivos de log. Para facilitar a análise pós-incidente e a detecção de ameaças, bem como para atender aos requisitos de conformidade, você deve reter uma quantidade suficiente de dados de log. O sinalizador --audit-log-maxsize define o tamanho máximo em megabytes (MB) do arquivo de log de auditoria antes da rotação ser realizada automaticamente. Ou esse sinalizador não está presente no comando para iniciar um servidor da API Kubernetes ou o tamanho máximo do arquivo de log de auditoria está definido para menos de 100 MB.

Exemplo 1: O comando a seguir inicia um servidor da API Kubernetes e define o sinalizador --audit-log-maxsize para 2 (megabytes), o que é insuficiente.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - ----audit-log-maxsize=2
    ...

A falta de registros de auditoria limita a capacidade de detectar e responder a incidentes relacionados à segurança e impede a investigação forense.

As definições de configuração que prejudicam os recursos de registro incluem, mas não estão limitadas a:
- desativar deliberadamente o log de auditoria
- isentar o log de ações de usuários, grupos ou processos específicos
- proteger inadequadamente a integridade do log
- não habilitar o log de auditoria opcional
- reduzir a taxa de amostragem de log

Se a configuração ProtectKernelDefaults não for definida ou for definida como false, um Kubelet poderá modificar os parâmetros do kernel em tempo de execução. Os parâmetros do kernel devem ser otimizados e reforçados antes da implantação do Kubernetes. Conceder a um Kubelet a capacidade de alterar os parâmetros do kernel expande a superfície de ataque do sistema operacional do host.

Exemplo 1: A configuração do Kubelet a seguir permite que um Kubelet configure os parâmetros do kernel devido à configuração ProtectKernelDefaults: false.

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

Há uma configuração que permite que o Kubelets atenda a solicitações anônimas. As solicitações anônimas não são rejeitadas por nenhum método de autenticação configurado. 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 anônimas para obter acesso a APIs de serviço com proteção insuficiente e sensíveis à segurança.

Exemplo 1: O arquivo de configuração a seguir permite que um Kubelet atenda a solicitações anônimas porque o campo anonymous está definido como enabled:true .

...
kind: KubeletConfiguration
...
authentication:
  anonymous:
    enabled: true
...

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
...