Cloud...precisamos falar de limites! (Parte 2/2)

Olá, escrevi esse artigo para o Tech Journal GFT na edição de Jun/2020 e publicado no Blog da GFT em Out/2020 (em inglês)

Aqui vou trazer para vocês a versão em Português e divido em duas partes, onde na primeira parte expliquei um pouco o que é Guardrails e seus conceitos, e nessa segunda vou explicar mais a parte técnica utilizando a ferramenta Cloud Custodian

Cloud Custodian

Quando falamos de Compliance As Code ou Governance As Code, temos algumas ferramentas disponíveis para nós, e uma delas e o Cloud Custodian, uma ferramenta open source desenvolvida pela Capital One, onde usa o YAML como sua linguagem principal e consegue aplicar suas políticas para AWS, Azure e GCP

O desenvolvimento das políticas do Custodian são bem simples e funciona basicamente com os alguns componentes principais

Name: O nome da sua apólice
Resource: O tipo de recurso que você usará, por exemplo: aws.rds, onde o provedor será AWS e o recurso RDS
Filter: É aqui onde iremos dizer quais critérios os recursos devem atender para nos dizer que possivelmente estão fora de conformidade
Mode: A forma como seu script funcionará, ou seja, se será executado sob demanda (pull), agendado por cron jobs (periodic) ou mesmo executado por meio de triggers em seu provedor de nuvem (trail)
Action: São as ações que tomaremos quando encontrarmos um recurso que atenda aos nossos filtros, desde colocar uma tag até destruir o recurso

Além disso, é possível criar filtros genéricos, onde podemos filtrar praticamente qualquer texto retornado da API em nuvem, através do JMESPath, e também criar ações customizadas, utilizando webhooks, onde por exemplo, se algum recurso for encontrado, podemos acionar um API externa que irá realizar alguma ação...e é aí que entra a criatividade!

Com o Cloud Custodian, além de criar seus Guardrails para compliance de segurança, podemos por exemplo, utilizá-lo também para gerar um catálogo de nossa infraestrutura, sem a necessidade de aplicar nenhuma ação, onde o Custodian pode navegar entre as regiões e assinaturas do seu player de nuvem

Bacana...mas, "show me the code"!

Vamos lá, agora vamos criar dois exemplos, ambos utilizando AWS, onde no primeiro você precisa verificar se há algum usuário IAM que tenha seu AccessKey com mais de 90 dias criado, e se encontrar, notificar um SQS; No segundo exemplo, vamos ver se algum usuário tentar criar um bucket S3 com acesso público habilitado (este é um clássico!), onde caso encontre, o bucket é automaticamente tageado (e podemos evoluir ele para uma exclusão)

Mas, antes de começarmos...

A instalação e configuração do Cloud Custodian é muito simples, pode ser feita via PIP, bem detalhada na documentação oficial, inclusive mostrando como se "conectar" com sua conta AWS, Azure ou Google, e depois de instalado, um comando que vai ajudar muito é...

$ custodian schema

...ele lista os recursos disponíveis para você criar suas politicas, onde você pode ir navegando entre eles até chegar a um "esqueleto" do que esse recurso tem disponível para você, por exemplo:

$ custodian schema aws.rds

Dica: Quando você for desenvolver suas policies, o Custodian irá fazer o scan procurando esses recursos, então você deve ter na sua conta para testar, e ao invés de ficar criando manualmente esses recursos pelo console, tente criar seus componentes baseando em IaC (por exemplo, Terraform, Cloudformation, etc...), onde dessa maneira você irá economizar bastante tempo entre um teste e outro...e quem sabe com aquele tempo que você ganhou não vai poder jogar boliche com quem você ama? ;)

Exemplo 1

Nesse primeiro exemplo, onde vamos verificar as chaves de acessos dos usuários IAM que tenham mais de 90 dias criado e se encontrar, vamos notificar um SQS, vamos usar o schema aws.iam...mas antes, vamos ver o que o Custodian nos diz quando executamos o schema do iam-user:

$ custodian schema aws.iam-user

O retorno dele será algo do tipo:

Show! Agora nós temos algumas dicas das "actions" e "filters", onde nesse caso vamos usar o filtro "access-key" e a action "notify", deixando nossa política assim:

Você percebeu que usei dois filtros? Ou seja, nossa policy "IAM-AccessKeys-Older-90-Days" só irá executar sua "actions" se ambos os "filters" forem retornados como verdadeiro! Bem bacana né?!

Exemplo 2

Nesse segundo exemplo, vamos procurar os buckets S3 que tenham o acesso público habilitado e adicionar uma TAG caso encontre...mas antes vamos dar uma olhada no "schema" do S3:

$ custodian schema aws.s3

Ele nos retornou algo parecido com:

Com isso, podemos escrever nossa policy, deixando ela mais ou menos assim:

Vocês perceberam que nesse arquivo temos duas policies? Ambas com o mesmo filtro, mas uma com o "mode" em "cloudtrail"...e o que isso significa? Que a primeira será executada on-demand, ou seja, irá adicionar a tag em buckets já existentes, e quando criarmos daqui para frente um novo bucket, o mode "cloudtrail" entra em ação. Quando usamos ele, na nossa conta será criado uma rule no EventBridge (Cloudwatch Alert) que irá monitorar nosso CloudTrail no evento que configuramos na policy (no caso o "PutBucketPolicy") e quando acionado, ele irá chamar um Lamba (provisionado também pelo C7N na nossa conta) que irá executar nossa "action", que nessa policy está configurada para adicionar a tag "Cloud-Custodian-S3-With-Public-Access"

Execução

Com as nossas policies criadas, agora é hora de executa-las, onde no terminal vamos rodar:

$ custodian run IAM-AccessKeys-Older-90-Days.yml -s custodian-output/

Nesse primeiro exemplo, nós vamos executar o arquivo IAM-AccessKeys-Older-90-Days.yml, e o parâmetro "-s" significa que todo o retorno da execução será armazenado no diretório "custodian-output", e como nessa primeira policy não temos nenhum "mode" definido (o padrão é "pull" que executa somente sob-demanda), ele será executado somente quando executarmos esse comando manualmente, retornando a quantidade e dados dos recursos localizados

Dicas:

Nesse diretório de output da execução do Custodian, ele irá gerar alguns arquivos .json que mostrará os recursos encontrados com todas suas propriedades, igual quando executamos o cli da AWS...ótimo para debug!
O Custodian armazena cache nas requisições, caso você não queria utilizar (gerando um falso positivo em alguns casos), você poderá adicionar o parâmetro "cache-period" igual a "0" na execução para ir para a api da AWS em toda execução, por exemplo:

$ custodian run IAM-AccessKeys-Older-90-Days.yml --cache-period 0 -s custodian-output/

Continuando...na segunda execução, faremos da seguinte forma:

$ custodian run Check-S3-Public.yml -d -s custodian-output/

Nessa execução, coloquei o parâmetro "-d", o que significa que iramos executar essa policy em modo "dry-run", ou seja, ele não irá executar nenhuma "action" e o "mode" dele será "pull", o que não persiste nenhum recurso na sua conta, uma maneira mais segura de validar suas policies, e depois de validado e tudo OK, basta remover o "-d" e executa-la novamente, onde ela irá persistir os eventos e execuções das "actions"

Resumo

Como eu disse acima, basta usar a criatividade para usar o Cloud Custodian onde ele pode ajudar nos seus problemas, não só de segurança, mas como ferramenta de inventário, controle de custos, automatizações, etc...imagina que você pode inclusive usar o Cloud Custodian para controlar o Cloud Custodian!...mas como assim? Imagina que você criou algumas policies que controlam algum recursos e quando encontra algum, adiciona uma determinada TAG, depois você pode criar uma segunda policy onde verifica quais recursos tem essa TAG e tomam outra ações, como por exemplo uma exclusão posterior, uma notificação para o Slack ou até mesmo alguma automação que invoca outra função! As possibilidades são enormes!