Segurança

• 1: Visão Geral da Segurança Cloud Native
• 2: Políticas de Segurança do Pod
• 3: Segurança para Nós Windows
• 4: Controlando Acesso à API do Kubernetes

1 - Visão Geral da Segurança Cloud Native

Esta visão geral define um modelo para pensar sobre a segurança em Kubernetes no contexto da Segurança em Cloud Native.

Os 4C da Segurança Cloud Native

Você pode pensar na segurança em camadas. Os 4C da segurança Cloud Native são a Cloud, Clusters, Contêineres e Código.

Cada camada do modelo de segurança Cloud Native é construída sobre a próxima camada mais externa. A camada de código se beneficia de uma base forte (Cloud, Cluster, Contêiner) de camadas seguras. Você não pode proteger contra padrões ruins de segurança nas camadas de base através de segurança no nível do Código.

Cloud

De muitas maneiras, a Cloud (ou servidores co-localizados, ou o datacenter corporativo) é a base de computação confiável de um cluster Kubernetes. Se a camada de Cloud é vulnerável (ou configurado de alguma maneira vulnerável), então não há garantia de que os componentes construídos em cima desta base estejam seguros. Cada provedor de Cloud faz recomendações de segurança para executar as cargas de trabalho com segurança nos ambientes.

Segurança no provedor da Cloud

Se você estiver executando um cluster Kubernetes em seu próprio hardware ou em um provedor de nuvem diferente, consulte sua documentação para melhores práticas de segurança. Aqui estão os links para as documentações de segurança dos provedores mais populares de nuvem:

Segurança de Infraestrutura

Sugestões para proteger sua infraestrutura em um cluster Kubernetes:

Cluster

Existem duas áreas de preocupação para proteger o Kubernetes:

• Protegendo os componentes do cluster que são configuráveis.
• Protegendo as aplicações que correm no cluster.

Componentes do Cluster

Se você deseja proteger seu cluster de acesso acidental ou malicioso e adotar boas práticas de informação, leia e siga os conselhos sobre protegendo seu cluster.

Componentes no cluster (sua aplicação)

Dependendo da superfície de ataque de sua aplicação, você pode querer se concentrar em tópicos específicos de segurança. Por exemplo: se você estiver executando um serviço (Serviço A) que é crítico numa cadeia de outros recursos e outra carga de trabalho separada (Serviço B) que é vulnerável a um ataque de exaustão de recursos e, por consequência, o risco de comprometer o Serviço A é alto se você não limitar os recursos do Serviço B. A tabela a seguir lista áreas de atenção na segurança e recomendações para proteger cargas de trabalho em execução no Kubernetes:

Contêiner

A segurança do contêiner está fora do escopo deste guia. Aqui estão recomendações gerais e links para explorar este tópico:

Código

O código da aplicação é uma das principais superfícies de ataque sobre a qual você tem maior controle. Embora a proteção do código do aplicativo esteja fora do tópico de segurança do Kubernetes, aqui são recomendações para proteger o código do aplicativo:

Segurança de código

Próximos passos

Saiba mais sobre os tópicos de segurança do Kubernetes:

• Padrões de segurança do Pod
• Políticas de rede para Pods
• Controle de acesso à API Kubernetes
• Protegendo seu cluster
• Criptografia de dados em trânsito for the control plane
• Criptografia de dados em repouso
• Secrets no Kubernetes
• Runtime class

2 - Políticas de Segurança do Pod

Em vez de usar PodSecurityPolicy, você pode aplicar restrições semelhantes em Pods usando um ou ambos:

• Admissão de segurança do pod
• um plug-in de admissão de terceiros, que você mesmo implanta e configura

Para obter um guia de migração, consulte Migre de PodSecurityPolicy para o controlador de admissão PodSecurity embutido. Para obter mais informações sobre a remoção desta API, veja Descontinuação de PodSecurityPolicy: passado, presente e futuro.

Se você não estiver executando o Kubernetes v1.30, verifique a documentação para sua versão do Kubernetes.

3 - Segurança para Nós Windows

Esta página descreve considerações de segurança e boas práticas específicas para o sistema operacional Windows.

Proteção para dados Secret nos Nós

No Windows, os dados do Secret são escritos em texto não-encriptado no armazenamento local do nó (em comparação ao uso de tmpfs / sistemas de arquivo em memória no Linux). Como um operador do cluster, você deve tomar as duas medidas adicionais a seguir:

1. Use ACLs em arquivos para proteger a localização do arquivo Secrets.
2. Aplique criptografia a nível de volume usando BitLocker.

Usuários dos Contêineres

RunAsUsername pode ser utilizado em Pods ou contêineres com Windows para executar os processos do contêiner como usuário específico. Isto é aproximadamente equivalente a RunAsUser.

Os contêineres Windows oferecem duas contas de usuário padrão, ContainerUser e ContainerAdministrator. As diferenças entre estas duas contas de usuário são descritas em When to use ContainerAdmin and ContainerUser user accounts dentro da documentação da Microsoft Secure Windows containers.

Os usuários locais podem ser adicionados às imagens do contêiner durante o processo de criação do mesmo.

Contêineres Windows também podem rodar como identidades do Active Directory usando Group Managed Service Accounts

Isolamento de segurança a nível do Pod

Mecanismos de contexto de segurança de Pod específicos para Linux (como SELinux, AppArmor, Seccomp, ou capabilities customizados para POSIX) não são suportados nos nós com Windows.

Contêineres privilegiados não são suportados no Windows. Em vez disso, contêineres HostProcess podem ser usados no Windows para realizar muitas das tarefas realizadas por contêineres privilegiados no Linux.

4 - Controlando Acesso à API do Kubernetes

Esta página fornece uma visão geral do controle de acesso à API do Kubernetes.

Usuários podem acessar a API do Kubernetes utilizando kubectl, bibliotecas, ou executando requisições REST. Ambos, usuários humanos e Contas de serviço do Kubernetes podem ser autorizados a acessar à API. Quando uma requisição chega à API, ela passa por diversos estágios, ilustrados no seguinte diagrama:

Segurança na camada de transporte

Em um cluster Kubernetes típico, a API fica disponível na porta 443, protegida por segurança na camada de transporte (TLS). O servidor de API apresenta um certificado. Este certificado pode ser assinado utilizando uma autoridade privada de certificados (CA), ou baseado em uma infraestrutura de chave pública ligada a uma autoridade de certificados reconhecida publicamente.

Se o seu cluster utiliza uma autoridade privada de certificados, voce precisa de uma cópia do certificado da autoridade de certificados (CA) dentro do arquivo de configuração ~/.kube/config, no lado do cliente, para que voce possa confiar na conexão e tenha a garantia de que não há interceptação de tráfego.

O seu cliente pode apresentar o certificado de cliente TLS neste estágio.

Autenticação

Uma vez em que a segurança na camada de transporte (TLS) é estabelecida, a requisição HTTP move para o passo de autenticação. Isto é demonstrado no passo 1 no diagrama acima. O script de criação do cluster ou configurações de administração configuram o servidor de API para executar um ou mais módulos autenticadores.

Autenticadores são descritos em maiores detalhes em Autenticação.

A entrada para o passo de autenticação é a requisição HTTP completa; no entanto, tipicamente são verificados os cabeçalhos e/ou o certificado de cliente.

Módulos de autenticação incluem certificados de cliente, senhas, tokens simples, tokens de auto-inicialização e JSON Web Tokens (utilizados para contas de serviço).

Vários módulos de autenticação podem ser especificados, em que cada um será verificado em sequência, até que um deles tenha sucesso.

Se a requisição não pode ser autenticada, será rejeitada com o código de status HTTP 401 (não autorizado). Caso contrário, o usuário é autenticado com um "nome de usuário" específico e o nome de usuário está disponível para as etapas subsequentes para usar em suas decisões. Alguns autenticadores também fornecem as associações de grupo do usuário, enquanto outros autenticadores não o fazem.

Enquanto o Kubernetes usa nomes de usuário para decisões de controle de acesso e no registro de requisições, ele não possui um objeto user nem armazena nomes de usuários ou outras informações sobre usuários em sua API.

Autorização

Após a requisição ser autenticada como originada de um usuário específico, a requisição deve ser autorizada. Isso é mostrado no passo 2 no diagrama.

Uma requisição deve incluir o nome do usuário requerente, a ação requisitada e o objeto afetado pela ação. A requisição é autorizada se uma política existente declarar que o usuário tem as devidas permissões para concluir a ação requisitada.

Por exemplo, se Bob possui a política abaixo, então ele somente poderá ler pods no namespace projectCaribou:

{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "bob",
        "namespace": "projectCaribou",
        "resource": "pods",
        "readonly": true
    }
}

Se Bob fizer a seguinte requisição, a requisição será autorizada porque ele tem permissão para ler objetos no namespace projectCaribou:

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "resourceAttributes": {
      "namespace": "projectCaribou",
      "verb": "get",
      "group": "unicorn.example.org",
      "resource": "pods"
    }
  }
}

Se Bob fizer uma requisição para escrever (create ou update) em objetos no namespace projectCaribou, sua autorização será negada. Se Bob fizer uma requisição para ler (get) objetos em um namespace diferente, como projectFish, sua autorização será negada.

A autorização do Kubernetes requer que você use atributos comuns a REST para interagir com os sistemas de controle de acesso existentes em toda uma organização ou em todo o provedor de nuvem utilizado. É importante usar a formatação REST porque esses sistemas de controle podem interagir com outras APIs além da API do Kubernetes.

O Kubernetes oferece suporte a vários módulos de autorização, como o modo de controle de acesso baseado em atributos (ABAC), o modo de controle de acesso baseado em função (RBAC) e o modo Webhook. Quando um administrador cria um cluster, ele configura os módulos de autorização que devem ser utilizados no servidor de API. Se mais de um módulo de autorização for configurado, o Kubernetes verificará cada módulo e, se algum módulo autorizar a requisição, a requisição poderá prosseguir. Se todos os módulos negarem a requisição, a requisição será negada (com código de status HTTP 403 - Acesso Proibido).

Para saber mais sobre a autorização do Kubernetes, incluindo detalhes sobre como criar políticas usando os módulos de autorização compatíveis, consulte Visão Geral de Autorização.

Controle de admissão

Os módulos de controle de admissão são módulos de software que podem modificar ou rejeitar requisições. Além dos atributos disponíveis para os módulos de Autorização, os módulos do controlador de admissão podem acessar o conteúdo do objeto que está sendo criado ou modificado.

Os controladores de admissão atuam em requisições que criam, modificam, excluem ou age como um proxy para outro objeto. Os controladores de admissão não agem em requisições que apenas leem objetos. Quando vários controladores de admissão são configurados, eles são chamados em ordem.

Isso é mostrado como etapa 3 no diagrama.

Ao contrário dos módulos de autenticação e autorização, se algum módulo controlador de admissão rejeita, a solicitação é imediatamente rejeitada.

Além de rejeitar objetos, os controladores de admissão também podem definir valores padrão complexos para campos.

Os módulos de Controle de Admissão disponíveis são descritos em Using Admission Controllers.

Após uma requisição passar por todos os controladores de admissão, ela é validada usando as rotinas de validação para o objeto de API correspondente e, em seguida, gravados no armazenamento de objetos (mostrado como etapa 4 no diagrama).

Auditoria

A auditoria do Kubernetes fornece um conjunto de registros cronológicos relevantes para a segurança que documentam a sequência de ações em um cluster. O cluster audita as atividades geradas pelos usuários, pelos aplicativos que usam a API do Kubernetes e pela própria camada de gerenciamento.

Para mais informações, consulte Auditing.

Portas e IPs do servidor de API

A discussão anterior se aplica a requisições enviadas para a porta segura do servidor de API (o caso típico). O servidor de API pode realmente servir em 2 portas.

Por padrão, o servidor da API Kubernetes atende HTTP em 2 portas:

1. Porta localhost:

   • destina-se a testes e auto-inicialização e a outros componentes do nó mestre (scheduler, controller-manager) para falar com a API
   • sem segurança na camada de transporte (TLS)
   • o padrão é a porta 8080
   • IP padrão é localhost, mude com a flag --insecure-bind-address.
   • a requisição ignora os módulos de autenticação e autorização .
   • requisição tratada pelo(s) módulo(s) de controle de admissão.
   • protegido pela necessidade de ter acesso ao host

2. “Porta segura”:

   • utilize sempre que possível
   • utiliza segurança na camada de transporte (TLS). Defina o certificado com --tls-cert-file e a chave com a flag --tls-private-key-file.
   • o padrão é a porta 6443, mude com a flag --secure-port.
   • IP padrão é a primeira interface de rede não localhost, mude com a flag --bind-address.
   • requisição tratada pelos módulos de autenticação e autorização.
   • requisição tratada pelo(s) módulo(s) de controle de admissão.
   • módulos de autenticação e autorização executados.

Próximos passos

Consulte mais documentação sobre autenticação, autorização e controle de acesso à API:

• Autenticação
  • Autenticando com Tokens de Inicialização
• Using Admission Controllers
  • Dynamic Admission Control
• Autorização
  • Using RBAC Authorization
  • Using ABAC Authorization
  • Using Node Authorization
  • Webhook Mode
• Certificate Signing Requests
  • incluindo Approval or rejection of Certificate Signing Requests e Signing certificates
• Contas de serviço
  • Configure Service Accounts for Pods
  • Managing Service Accounts

Você pode aprender mais sobre:

• como os pods podem usar Secrets para obter credenciais de API.