Usando o OPA para validar modelos do Amazon EKS Blueprint

Por Piyush Mattoo e  Hans Nesbitt

À medida que as organizações adotam tecnologias de containers, como o Kubernetes, o desafio de garantir a segurança e a conformidade se torna cada vez mais complexo. Com ambientes Kubernetes que abrangem infraestrutura como código (IaC) e clusters Kubernetes, manter uma postura segura pode ser uma tarefa difícil. Para lidar com essa complexidade e reduzir os riscos, muitas equipes estão recorrendo a ferramentas padronizadas.

As organizações que executam cargas de trabalho baseadas em Kubernetes descobriram o poder dos web-hooks de admissão como um componente essencial de sua estratégia de segurança. Os web-hooks de admissão, quando combinados com ferramentas como o Open Policy Agent (OPA), abrem uma série de possibilidades para aprimorar a segurança e a conformidade em todo o conjunto tecnológico. O OPA é um mecanismo de políticas de uso geral de código aberto e é uma ferramenta versátil que permite a aplicação de políticas não apenas no Kubernetes, mas também no nível de IaC. Isso permite que a organização aplique políticas em vários tipos de recursos. Para saber mais sobre o OPA, visite o repositório do GitHub.

Nesta publicação, exploramos os benefícios de usar o OPA para avaliar seu Amazon EKS Blueprints for Terraform como código e como ele pode ajudar você a manter um ambiente seguro e compatível.

Visão geral da solução

O Amazon EKS Blueprints for Terraform contém padrões que podem ser usados por usuários, parceiros e equipes internas da AWS. Os EKS Blueprints ajudam na configuração e no gerenciamento de clusters completos do Amazon Elastic Kubernetes Service (Amazon EKS) que são totalmente inicializados com o sistema operacional necessário para implantar e operar cargas de trabalho. Os EKS Blueprints permitem que os usuários adotem as melhores práticas e comecem a integrar cargas de trabalho em dias, em vez de meses. Embora as organizações permitam que as equipes se movam rapidamente, elas também querem fornecer proteções para garantir que os recursos sejam configurados de acordo com as melhores práticas.

Essas grades de proteção podem ser adotadas para auditar a configuração em execução dos recursos, bem como para testar os recursos antes da implantação. Ao implementar verificações de conformidade como parte de seu pipeline de IaC, você pode tentar detectar violações de conformidade no início do processo de desenvolvimento e impedir que elas sejam implantadas na produção. Isso pode economizar tempo e recursos na correção de problemas posteriores e na redução da probabilidade de problemas de não conformidade surgirem durante auditorias ou inspeções.

Estamos analisando como usar o OPA para avaliar a conformidade dos arquivos do plano do Terraform (consulte o Diagrama 1). Esse processo pode ajudar a garantir a conformidade da configuração do seu recurso antes da implantação. As grades de proteção da OPA são escritas na linguagem política conhecida como Rego. Algumas das verificações que estamos analisando como parte desta postagem são:

• Validar se o cluster tem um grupo de segurança definido
• Validar se o cluster está configurado como privado

Validar o tamanho do disco do nó de trabalho

Diagrama 1 Fluxo de trabalho de solicitação/resposta do OPA

Pré-requisitos

Antes de continuar, você deve ter os seguintes pré-requisitos:

• Uma conta da AWS
• Instale o AWS Command Line Interface (AWS CLI) versão 2 em sua máquina local.
• Instale o Open Policy Agent a partir da versão mais recente
• Instale o Terraform

Passo a passo

As etapas a seguir orientam você nesta postagem.

Clone o repositório de código localmente

Usamos dois repositórios de código juntos para implantar e gerenciar clusters EKS ao mesmo tempo em que aplicamos as políticas e as melhores práticas definidas nas regras do OPA.

git clone https://github.com/aws-ia/terraform-aws-eks-blueprints.git

Esse repositório contém uma coleção de padrões de cluster EKS implementados no código do Terraform para implantar e gerenciar clusters EKS e recursos relacionados da AWS

git clone https://github.com/aws-samples/aws-infra-policy-as-code-with-terraform.git

Esse repositório contém políticas de OPA para testar a infraestrutura do Amazon EKS em relação ao plano Terraform.

Crie um plano Terraform

Para começar a avaliar nosso IaC, precisamos inicializar o Terraform. Depois de inicializado, executamos o comando terraform plan, que cria um plano de execução. Isso permite que você visualize as alterações que o Terraform planeja fazer em sua infraestrutura. Depois de concluído, revisamos a saída de ‘tfplan.json’.

terraform -chdir=terraform-aws-eks-blueprints/patterns/fargate-serverless/ init
terraform -chdir=terraform-aws-eks-blueprints/patterns/fargate-serverless/ plan --out tfplan.binary
terraform -chdir=terraform-aws-eks-blueprints/patterns/fargate-serverless/ show -json tfplan.binary > tfplan.json

cat tfplan.json 

Agora que temos nosso plano, podemos começar a avaliá-lo com a OPA.

Avalie o grupo de segurança do cluster

A primeira regra de OPA avaliada em relação ao nosso plano Terraform é para o grupo de segurança do cluster. Essa regra valida a presença do grupo de segurança do cluster. Para fazer isso, usamos o comando Opa eval, que avalia as expressões e políticas do Rego.

opa eval -i tfplan.json \
-d aws-infra-policy-as-code-with-terraform/policy-as-code/OPA/policy/aws/eks/aws-eks-m-3.rego \
-d aws-infra-policy-as-code-with-terraform/policy-as-code/OPA/policy/common.utils.rego "data.aws.eks.m3.deny"

O parâmetro -i define o documento de entrada do plano do Terraform para a avaliação e o -d define as políticas do OPA. Esse comando deve gerar o seguinte JSON:

{
    "result": [
        {
            "expressions": [
                {
                    "value": [
                        "AWS-EKS-M-3: 'module.eks.aws_eks_cluster.this[0]' EKS Cluster Should have cluster security group defined"
                    ],
                    "text": "data.aws.eks.m3.deny",
                    "location": {
                        "row": 1,
                        "col": 1
                   }
               }
             ]
        }
    ]
}

Depois de executar essa verificação, podemos ver que há um valor com a mensagem “O cluster EKS deve ter o grupo de segurança do cluster definido”. Isso nos diz que o cluster atualmente não tem um grupo de segurança definido.

Vamos revisar o código Rego que fez essa avaliação. Você pode visualizar o conteúdo executando o seguinte comando:

cat aws-infra-policy-as-code-with-terraform/policy-as-code/OPA/policy/aws/eks/aws-eks-m-3.rego

Saída:

is_in_scope(resource) {
  resource.mode == "managed"
  data.utils.is_create_or_update(resource.change.actions)
  resource.type == "aws_eks_cluster"
}

is_security_group_enabled(resource){
  resource.change.after.vpc_config[0].security_group_ids
  count(resource.change.after.vpc_config[0].security_group_ids) > 0
} else {
  resource.change.after_unknown.vpc_config[0].security_group_ids == true
} else = false{
  true
}

deny[reason] {
  resource := input.resource_changes[_]
  is_in_scope(resource)
  not is_security_group_enabled(resource)
  reason := sprintf("AWS-EKS-M-3: '%s' EKS Cluster Should have cluster security group defined", [resource.address])

Invocamos a função deny, que avalia o documento de entrada do plano do Terraform verificando se o modo de recurso é gerenciado, se o tipo de recurso é aws_eks_cluster e se o cluster tem um grupo de segurança definido. Em caso de falha na avaliação, retornamos o motivo na função de negação descrevendo o motivo da falha.

Vamos mudar isso e executar novamente nossa verificação. Edite a configuração do cluster no seguinte arquivo ‘terraform-aws-eks-blueprints/patterns/fargate-serverless/main.tf’ para permitir a criação do grupo de segurança do cluster.

Execute o seguinte comando:

sed -i '' 's/create_cluster_security_group = false/create_cluster_security_group = true/g' terraform-aws-eks-blueprints/patterns/fargate-serverless/main.tf

Precisamos criar um novo arquivo de plano do Terraform para testar a nova configuração. Remova os arquivos tfplan criados anteriormente.

rm terraform-aws-eks-blueprints/patterns/fargate-serverless/tfplan.binary
rm tfplan.json

terraform -chdir=terraform-aws-eks-blueprints/patterns/fargate-serverless/ init
terraform -chdir=terraform-aws-eks-blueprints/patterns/fargate-serverless/ plan --out tfplan.binary
terraform -chdir=terraform-aws-eks-blueprints/patterns/fargate-serverless/ show -json tfplan.binary > tfplan.json

Agora, vamos executar novamente a definição de verificação do grupo de segurança do cluster:

opa eval -i tfplan.json \
-d aws-infra-policy-as-code-with-terraform/policy-as-code/OPA/policy/aws/eks/aws-eks-m-3.rego \
-d aws-infra-policy-as-code-with-terraform/policy-as-code/OPA/policy/common.utils.rego "data.aws.eks.m3.deny"

O cluster EKS tem o grupo de segurança configurado.

Saída:

{
  "result": [
    {
      "expressions": [
        {
          "value": [],
          "text": "data.aws.eks.m3.deny",
          "location": {
            "row": 1,
            "col": 1
          }
        }
      ]
    }
  ]
}

Validar se o cluster é privado

Em seguida, executamos uma verificação para validar se o cluster EKS está configurado para ser privado. Um cluster privado permite que as chamadas de API do Kubernetes na VPC do seu cluster (como a comunicação entre o nó e o plano de controle) usem o endpoint privado da VPC e o tráfego permaneça na VPC do seu cluster.

opa eval -i tfplan.json \
-d aws-infra-policy-as-code-with-terraform/policy-as-code/OPA/policy/aws/eks/aws-eks-m-2.rego \
-d aws-infra-policy-as-code-with-terraform/policy-as-code/OPA/policy/common.utils.rego "data.aws.eks.m2.deny"

Saída:

{
 "result": [
    {
    "expressions": [
        {
        "value": [
           "AWS-EKS-M-2: 'module.eks.aws_eks_cluster.this[0]' EKS Cluster should have only private endpoints"
        "text": "data.aws.eks.m2.deny",
        "location": {
        "row": 1,
        "col": 1
         }
        }
        ]
     }
  ]
}

Depois de executar essa verificação, podemos ver que há um valor com a mensagem “O EKS Cluster deve ter apenas endpoints privados”. Isso nos diz que o cluster atualmente permite o tráfego da Internet para o plano de controle. Vamos mudar isso e executar novamente nossa verificação. Edite a configuração do cluster no seguinte arquivo ‘terraform-aws-eks-blueprints/patterns/fargate-serverless/main.tf’ para tornar o cluster privado.

Execute o seguinte comando:

sed -i '' 's/cluster_endpoint_public_access = true/cluster_endpoint_public_access = false/g' terraform-aws-eks-blueprints/patterns/fargate-serverless/main.tf

Precisamos criar um novo arquivo de plano do Terraform para testar a nova configuração.

rm terraform-aws-eks-blueprints/patterns/fargate-serverless/tfplan.binary
rm tfplan.json

terraform -chdir=terraform-aws-eks-blueprints/patterns/fargate-serverless/ init
terraform -chdir=terraform-aws-eks-blueprints/patterns/fargate-serverless/ plan --out tfplan.binary
terraform -chdir=terraform-aws-eks-blueprints/patterns/fargate-serverless/ show -json tfplan.binary > tfplan.json

Agora, vamos executar novamente a verificação do cluster de endpoint privado:

opa eval -i tfplan.json \
-d aws-infra-policy-as-code-with-terraform/policy-as-code/OPA/policy/aws/eks/aws-eks-m-2.rego \
-d aws-infra-policy-as-code-with-terraform/policy-as-code/OPA/policy/common.utils.rego "data.aws.eks.m2.deny"

Agora, o cluster EKS está configurado como privado.

Saída:

{
 "result": [
    {
    "expressions": [
        {
        "value": [],
        "text": "data.aws.eks.m2.deny",
        "location": {
        "row": 1,
        "col": 1
         }
        }
      ]
    }
  ]
}

Validar o tamanho do disco

Para a próxima regra, avaliamos se os grupos de nós do cluster têm o parâmetro disk_size configurado. Como estamos usando o padrão sem servidor Fargate, essa regra deve ser aprovada.

opa eval -i tfplan.json \
-d aws-infra-policy-as-code-with-terraform/policy-as-code/OPA/policy/aws/eks/aws-eks-r-2.rego \
-d aws-infra-policy-as-code-with-terraform/policy-as-code/OPA/policy/common.utils.rego "data.aws.eks.r2.deny"

Saída:

{
  "result": [
    {
      "expressions": [
        {
          "value": [],
          "text": "data.aws.eks.r2.deny",
          "location": {
            "row": 1,
            "col": 1
          }
        }
      ]
    }
  ]
}

Essa é uma técnica de avaliar um Amazon EKS Blueprint e pode ser expandido para incluir outras verificações no seu ambiente, como o tipo de instância do Amazon Elastic Compute Cloud (Amazon EC2) ou até mesmo em outros recursos da AWS, como uma tabela do Amazon DynamoDB que também está sendo configurada como privada.

Conclusão

Usar o OPA para avaliar seu IaC e dentro de seu cluster Kubernetes é uma maneira inteligente e eficaz de garantir a segurança e a conformidade do seu ambiente. Ao aproveitar o OPA, você pode aplicar políticas em grande escala, reduzir o risco de configurações incorretas e vulnerabilidades e simplificar as auditorias de conformidade. A flexibilidade e a compatibilidade da OPA com várias ferramentas e plataformas a tornam uma excelente opção para organizações que buscam adotar uma abordagem baseada em políticas para infraestrutura em nuvem e conteinerização. Em última análise, implementar o OPA como parte de sua estratégia de segurança e conformidade pode ajudá-lo a proteger melhor os ativos e a reputação da sua organização diante das ameaças cibernéticas em constante evolução.

Esta postagem demonstra que, usando as políticas do Amazon EKS Blueprints e OPA Rego, você pode automatizar os controles preventivos do Kubernetes usando o IaC. Como resultado, os clusters Kubernetes só podem ser implantados no ambiente se estiverem em conformidade com todas as políticas de controle exigidas pela empresa. E com o poder dos serviços da AWS, podemos codificar e automatizar todo o processo de validação e implantação de ponta a ponta, o que acelera sua adoção do Amazon EKS e a implantação de cargas de trabalho do Kubernetes, mantendo a conformidade com as políticas de controle corporativo.

O OPA não é a única maneira para fazer isso, alguns usuários da AWS têm outras ferramentas que já adotaram. Se você usa as políticas do Terraform Cloud e do Sentinel, esta postagem mostra passo a passo como obter resultados semelhantes.

Este blog é uma tradução do blog original em inglês (link aqui ).

Biografia do autor

Piyush Mattoo é arquiteto de soluções para empresas na Amazon Web Services. Ele é líder em tecnologia de software com mais de 15 anos de experiência na criação de sistemas de software escaláveis e distribuídos que exigem uma combinação de amplas habilidades em forma de T em várias tecnologias. Ele tem formação educacional em Ciência da Computação com mestrado em Ciência da Computação e da Informação pela Universidade de Massachusetts.

Hans Nesbitt é arquiteto sênior de soluções na AWS, com sede no sul da Califórnia. Ele trabalha com clientes em todo o oeste dos EUA para criar arquiteturas de nuvem altamente escaláveis, flexíveis e resilientes.

Biografia do tradutor

Daniel Abib é arquiteto de soluções sênior na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem. https://www.linkedin.com/in/danielabib/

Biografia do Revisor

Marcelo Moras é Arquiteto de Soluções na AWS atendendo clientes Enterprise com foco em mercado financeiro. Com mais de 15 anos de experiência atuando com infraestrutura, administração de sistemas, redes, containers e segurança.