Como automatizar a segurança de contêineres no estilo de política como código usando CRD



Mostraremos como usar o Kubernetes CRD para automatizar a segurança e proteger seus aplicativos.

Tradução da equipe da revista Tomorrow Cloudy Mail.ru Cloud Solutions . Fonte: Niteen Kole Como automatizar a segurança do contêiner usando CRDs para obter a política de segurança como código com extras .

Por que você precisa de CRD


A segurança tem sido uma dor de cabeça para as equipes de DevOps . As ferramentas de software existentes resolvem com êxito os problemas de automatização da montagem e distribuição de aplicativos - o lançamento automático de aplicativos com base em contêineres se tornou o padrão. Ao mesmo tempo, a automação das configurações de segurança está muito atrasada.

Você pode implementar a verificação automatizada de vulnerabilidades, mas a necessidade de configurar manualmente as políticas de segurança de aplicativos está se tornando uma dor de cabeça.

A introdução das CRDs (definições de recursos personalizados) do Kubernetes ajudará a resolver problemas com a definição de políticas de segurança como código no estágio inicial de montagem e distribuição de aplicativos, além de automatizar seu uso ao implantar aplicativos no ambiente de produção.

O CRD pode ser usado para implementar políticas de segurança global que definem o comportamento do aplicativo e configuram a segurança de vários clusters do Kubernetes usados.

Usando o CRD para automação e definindo configurações de segurança centralmente como código, você pode apertar simultaneamente as configurações de segurança e simplificar sua aplicação. Em última análise, isso faz com que os aplicativos se tornem mais eficientes, com menos erros e, mais importante, mais seguros.

Como funciona a CRD?


Para definir políticas de segurança, usaremos o NeuVector CRD dentro da plataforma de contêiner NeuVector . Alternativas ao NeuVector para segurança de contêineres: AquaSec, StackRox, Sysdig Secure, Twistlock.

O NeuVector CRD contém políticas que primeiro coletam um perfil completo do comportamento normal do aplicativo.

O comportamento coletado é adicionado à lista branca, incluindo todas as regras de rede, processos, protocolos e operações de arquivo. Tudo isso juntos constitui um conjunto de operações de aplicativos padrão. Em seguida, as configurações de segurança são aplicadas, permitindo apenas conexões de rede confirmadas dentro dos contêineres que compõem o aplicativo. Essas conexões são identificadas durante a inspeção da camada 7 do modelo OSI (camada do protocolo de aplicação). Assim, qualquer tentativa de conexão externa não autorizada será impedida.

As políticas de segurança impedirão que os invasores usem comunicações dentro ou fora de contêineres para usar o aplicativo para seus próprios fins.

O CRD permite definir regras globais e regras para cada serviço separadamente. Os CRDs também são compatíveis com o Kubernetes RBAC, permitindo que você use contas de serviço e funções do Kubernetes para impor políticas de segurança.

Além disso, o controle de versão está disponível para criar suas próprias políticas para cada versão do aplicativo; a integração com os utilitários de gerenciamento de políticas de segurança, como o Open Policy Agent, é suportada . Clusters Kubernetes

prontos para uso com um sistema de monitoramento especialmente adaptado baseado em Prometheus e Grafana, além de TLS e RBAC para gerenciar direitos de acesso e padronizar o desenvolvimento em equipes distribuídas, podem ser testados gratuitamente na nuvem Mail.ru Cloud Solutions.

Criação do NeuVector CRD


O NeuVector CRD permite que você use arquivos YAML Kubernetes nativos para criar regras de segurança.

Crie um arquivo nvsecurityrule.yaml contendo uma descrição do NeuVector CRD. Este arquivo controla NvSecurityRulea natureza namespacede NvClusterSecurityRuleo cluster.

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: nvsecurityrules.neuvector.com
spec:
  group: neuvector.com
  names:
    kind: NvSecurityRule
    listKind: NvSecurityRuleList
    plural: nvsecurityrules
    singular: nvsecurityrule
  scope: Namespaced
  version: v1
  versions:
  — name: v1
    served: true
    storage: true

---

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: nvclustersecurityrules.neuvector.com
spec:
  group: neuvector.com
  names:
    kind: NvClusterSecurityRule
    listKind: NvClusterSecurityRuleList
    plural: nvclustersecurityrules
    singular: nvclustersecurityrule
  scope: Cluster
  version: v1
  versions:
  — name: v1
    served: true
    storage: true

Para criar um CRD, execute:

$ kubectl create -f nvsecurityrule.yaml

Assim que o NeuVector CRD for criado, todos os recursos criados posteriormente com o parâmetro kind: NvSecurityRuleserão processados ​​por este CRD. Assim, você pode criar seus próprios recursos com políticas de segurança conectadas. Antes de fazer qualquer coisa, é aconselhável estudar a documentação NeuVector e adicione o necessário clusterrolese clusterrolebindings.

Além disso, o uso desse CRD para aplicar políticas de segurança NeuVector em um cluster Kubernetes requer configurações de direitos apropriadas (RBAC). As políticas de segurança definidas pelo CRD para qualquer espaço para nome só podem ser aplicadas por um usuário com o direito de implantar no espaço para nome especificado. A aplicação de políticas de segurança a um cluster requer privilégios de administrador de cluster.

Abaixo está um trecho de código de teste de demo-security-v1.yaml, que restringe os contêineres nginx-podno espaço demopara nome , fornecendo acesso a outros contêineres do mesmo espaço para nome apenas via HTTP.

apiVersion: v1
items:
- apiVersion: neuvector.com/v1
  kind: NvSecurityRule
  metadata:
    name: nv.nginx-pod.demo
  spec:
    egress:
    — Selector:
        criteria:
        — key: service
          op: =
          value: node-pod.demo
        — key: domain
          op: =
          value: demo
        name: nv.node-pod.demo
      action: allow
      applications:
      - HTTP
      name: nv.node-pod.demo-egress-0
      ports: any
    — Selector:
        criteria:
        — key: service
          op: =

Abaixo do snippet, deve haver uma descrição de todas as conexões de rede permitidas para contêineres no espaço demopara nome , por exemplo, conexões com o servidor redis, bem como processos e atividades de disco permitidos para cada contêiner. Não se esqueça de implantar primeiro as políticas de segurança NeuVector e depois implantar o aplicativo. Assim, as políticas de segurança entrarão em vigor a partir do momento em que o aplicativo for iniciado.

Para aplicar uma política de segurança:

$ kubectl create -f demo-security-v1.yaml

O NeuVector lê as políticas de segurança nos recursos criados e usa a API REST para contatar o controlador NeuVector, que cria as regras e configurações de acordo com as políticas de segurança transferidas.

Opções para aplicar diretivas de segurança como código


O uso de políticas de segurança como código abre muitas oportunidades para os comandos e programadores do DevOps / DevSecOps. Aqui estão alguns exemplos.

Desenvolvimento e teste de manifestos de segurança no estágio inicial de criação de aplicativos


Os desenvolvedores podem usar o CRD para tornar o aplicativo mais seguro nos estágios iniciais de desenvolvimento. Eles podem fazer manifestos simultaneamente para implantar e aplicar políticas de segurança.

Após montar a imagem, verificar automaticamente as vulnerabilidades e aprovar a equipe do DevOps, o DevOps pode verificar os manifestos e fazer recomendações à equipe de desenvolvimento do ponto de vista da segurança. Novos aplicativos serão implantados juntamente com políticas de segurança eficazes, desde a primeira implantação até a produção.



Usando análise comportamental para criar políticas de segurança


As equipes do DevOps podem usar os recursos de análise comportamental do NeuVector em ambientes de teste para desenvolver políticas de segurança e criar arquivos yaml adequados para uso no NeuVector CRD.

A figura a seguir, começando no canto inferior direito do diagrama, mostra como sua equipe de DevOps implementa o aplicativo em um ambiente de teste, onde é realizada uma análise completa do comportamento do aplicativo e são formados perfis de segurança para a rede, atividade e processos de arquivo.

Essas regras são exportadas e transmitidas aos desenvolvedores que fazem os ajustes necessários e ao DevOps, que os testam antes de usá-los na produção.



Políticas de segurança global


O NeuVector CRD permite definir políticas de segurança global que não estão vinculadas a um aplicativo específico ou a um grupo de aplicativos em um cluster. Por exemplo, sua equipe de segurança ou implantação pode definir regras de rede global para bloquear todas as conexões em todos os contêineres ou para configurar o acesso de monitoramento a todos os processos no cluster.



Usando políticas de segurança comuns e políticas de segurança de aplicativos em conjunto, você pode criar configurações de segurança complexas e precisas necessárias à sua organização.

A seguir, é apresentado um exemplo de proibição de conexões ssh de contêineres para o exterior:

- apiVersion: neuvector.com/v1
  kind: NvClusterSecurityRule
  metadata:
    name: containers
    namespace: default
  spec:
    egress: []
    file: []
    ingress:
    — Selector:
        criteria: []
        name: external
      action: deny
      applications:
      - SSH
      name: containers-ingress-0
      ports: tcp/22
    process:
    — action: deny
      name: ssh
      path: /bin/ssh
    target:    
      Selector:
        criteria:
        — key: container
          op: =
          value: '*'
        name: containers
      policymode: null
    version: v1  
 

Migrando diretivas de segurança do teste para a produção


Com o NeuVector CRD, você pode controlar a migração automática de políticas de segurança - todas ou apenas aquelas necessárias - do ambiente de teste para o ambiente de produção. No console do NeuVector, você pode configurar o modo de novos serviços para detecção, monitoramento ou proteção.

Escolher um modo de monitoramento ou proteção significa que qualquer implantação ou atualização de serviço incluirá necessariamente a configuração das políticas de segurança definidas por você. Assim, o serviço entrará no estado ativo somente após a aplicação de políticas de segurança.

Usando os recursos do Kubernetes CRD e políticas de segurança como código, seus desenvolvedores e DevOps poderão aplicar a automação de políticas de segurança para aplicativos e garantir que os aplicativos estejam muito melhor protegidos em todos os estágios: desde o início do desenvolvimento até o trabalho em produção.


All Articles