DEV Community: Felipe KiKo

Utilizando o AWS Cloudfront como CDN no Moodle

Felipe KiKo — Sat, 23 Apr 2022 12:36:25 +0000

Olá!

Hoje vou explicar como implementar o AWS Cloudfront, serviço de CDN da AWS, em instalações do Moodle...mas antes

O que é CDN e qual vantagem tenho em usar ele?

O Content Delivery Networks, ou CDN, é um mecanismo de distribuição de conteúdo que tem como objetivo fazer a entrega de arquivos de forma mais eficaz, usando pontos de distribuição próximos aos usuários

...OK, mas no Moodle, o que isso faz de diferença?

Como qualquer outra aplicação web, o Moodle possui alguns arquivos estáticos, que quem faz essa distribuição comumente são as instâncias de aplicação, onde está sendo executado o PHP, e por conta disso, todo o tráfego de saída é da EC2, onde só nisso já contamos com uma economia, pois o tráfego de saída do Cloudfront é mais barato comparado ao da EC2, e ainda conta com Free Tier para o Data Transfer Out

E além disso, como expliquei mais acima, o CDN tem como um dos objetivos fazer a entrega mais eficaz do conteúdo, logo, se sua instância estiver localizada, por exemplo, em Virginia (us-east-1) e seus usuários localizados no Brasil, se tivermos o Cloudfront na frente da entrega de conteúdo da aplicação, ela será feita nos pontos de acesso do Cloudfront, aumentando o tempo de resposta dessa entrega do seu conteúdo

Só vantagem né? Então agora vamos colocar a mão na massa!

Pré Requisitos

Antes de tudo, vamos partir do princípio que você já tenha sua aplicação Moodle configurada (na AWS) e sendo executada normalmente, entregando seu conteúdo por um Load Balancer e o DNS tudo bonitinho...certo?

Para essa configuração, vamos criar os seguinte componentes:

Cloudfront
Bucket S3 para hospedagem dos arquivos estáticos

Criando o Cloudfront

No serviço "Cloudfront" no console da AWS, clique em "Create Distribution"

Nesse primeiro passo, vamos criar a nossa primeira origem de dados, que será o Load Balancer, então em "Origin domain" selecione o seu Load Balancer

Em "Protocol", selecione o que você já esteja usando (recomendo utilizar HTTPS e marcar "Match viewer" para ele responder tanto na 80 como na 443)

O restante pode deixar como está

Na sessão "Default cache behavior", o único ponto que vamos mudar é o "Allowed HTTP methods" para permitir todos os verbos, selecionando "GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE" e marcando o "OPTIONS"

Em "Settings", vamos adicionar o endereço da aplicação em "Alternate domain name (CNAME) - optional" e caso esteja usando SSL (espero que sim!), selecione o seu certificado em "Custom SSL certificate - optional"

Pronto, pode clicar em "Create Distribution" e aguardar finalizar o deploy...mas ainda não acabou, temos ainda mais algumas coisinhas para configurar

Adicionando o Behavior do S3

Após nosso Cloudfront ser "deployado", vamos criar a origem apontando para o S3, mas antes precisamos enviar nossos arquivos estáticos para o bucket que criamos na etapa de pré-requisitos

Como temos limites da quantidade de behaviors que podemos cadastrar, vamos enviar somente os arquivos que mais tem requisições dentro do moodle

No seu servidor, instale e configure o AWS CLI caso ainda não tenha feito, e dentro do diretório onde está o source do seu moodle, execute o comando:

# Vamos criar um diretorio temporario
mkdir tmp_cloudfront

# Busca e copia somente os arquivos com as extensoes abaixo
find . -type f -iregex '.*\.\(css\|gif\|html\|htm\|jpg\|js\|scss\|png\|svg\|ttf\|woff2\)' -exec cp --parents {} tmp_cloudfront \;

# Envia os arquivos para o bucket S3
aws s3 sync tmp_cloudfront/ s3://CAMINHO DO SEU BUCKET/

# Remove o diretorio temporario
rm tmp_cloudfront

Pronto, agora precisamos criar nossa origem no Cloudfront, e para isso, no console da AWS dentro do serviço Cloudfront, clique na sua distribuição (que criamos na etapa anterior) e vá na aba "Origins" e clique em "Create origin"

Em "Origin domain", selecione o bucket S3 que você criou, em "S3 bucket access" selecione "Yes use OAI (bucket can restrict access to only CloudFront)" e clique em "Create new OAI" e em "Bucket policy" selecione "Yes, update the bucket policy". O restante pode manter do jeito que está

Uma vez com nossas origens cadastradas, vamos cadastrar os behaviors! Essa é a parte mais chatinha do processo...Vá na aba "Behaviors" e clique em "Create behavior"

Nesse processo, vamos cadastrar os behaviors referente a entrega de arquivos estáticos do Moodle que são feitas pelo PHP, então vamos cadastrar 8 behaviors:

lib/.php/
lib/editor/tinymce/plugins/loader.php/*
theme/yui_combo.php
theme/.php/
/pluginfile.php*
plugins/loader.php/*
draftfile.php/*
*.php

Todos eles apontando para seu Load Balancer em "Origin and origin groups" e em "Allowed HTTP methods" selecionado "GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE" com "OPTIONS" selecionado

Alem disso, vamos modificar o "Cache key and origin requests", alterando para "Legacy cache settings", onde no "Headers" vamos deixar com "Include the following headers" e em "Add header" vamos adicionar "Host"; Em "Query strings" e "Cookies", selecione "All"

E agora, vamos criar todos os behaviors para todas as extensões dos arquivos estáticos que enviamos para o nosso S3, então a única parte que irá mudar em cada etapa é a "Path pattern", onde devemos colocar a extensão correspondente, por exemplo: *.css, *.png, etc...

Em "Origin and origin groups" vamos selecionar nosso bucket S3, o restante podemos manter do jeito que está

Muito importante seguir a ordem de cadastrar, deixando no topo os behaviors que vão ser entregues pelo PHP e depois os estáticos, senão podemos ter problema na ordem de entrega do conteúdo

Vai ficar mais ou menos assim quando você finalizar de cadastrar todos os behaviors

E pronto! Seu Cloudfront está configurado! Agora basta modificar seu DNS para responder no "Distribution domain name"

Uma última coisa bem importante...os Deploys!

Caso você instale um novo plugin ou faça alguma alteração no seu código fonte, é necessário atualizar esses arquivos também no seu bucket S3

Além disso, você vai precisar fazer uma invalidação do cache para refletir as novas alterações, e para isso basta entrar na sua distribuição, ir em "Invalidations" e "Create invalidation", e no "Add object paths" podemos colocar para invalidar todo o cache, colocando /*

Até mais e muito obrigado pela Leitura! Ah, e se sentiu falta de alguma informação, algo que possa estar errado ou se quiser tirar dúvidas, fiquem a vontade de comentar! 😃

Configurando o Amazon QuickSight para custos na AWS

Felipe KiKo — Fri, 01 Apr 2022 23:05:55 +0000

Olá!

Quando queremos controlar nossos custos na AWS, a imagem sempre que vem a cabeça é a de dashboards e reports, certo?

Com o Amazon QuickSight conseguimos montar essas visualizações de uma maneira bem simples e profissional!

Nesse artigo rápido vou mostrar o passo-a-passo de como configurar do zero o QuickSight + CUR (Cost and Usage Report) da AWS

1. Criando seu Cost and Usage Reports

O primeiro passo é configurar um CUR para que a AWS envie os dados de custo da(s) sua(s) conta(s). Caso você tenha diversas contas (controladas pela Organization), você poderá configurar na sua Payer Account, pois ai terá todos os dados de todas as contas, senão pode seguir na sua conta individual

No serviço de "Billing", vá em "Cost & Usage Reports" e clique em "Create Report"; Nessa primeira tela será solicitado o nome do seu report

Dica: Caso você queria mais detalhes no reports, selecione "Include resource IDs", pois ele irá adicionar os IDs dos recursos...mas cuidado, dependendo da utilização da sua conta, isso poderá aumentar bem a quantidade de registros nos seus reports, por consequência os custos

Na próxima tela você irá configurar o bucket onde a AWS irá enviar os reports, e selecionar a integração com Amazon Athena

Dica 1: Crie um novo bucket dedicado somente para esses reports

Dica 2: Caso você queria detalhes por hora dos seus custos, para controlar por exemplo em qual horário temos mais utilização de recursos, marque a granularidade para "Hourly", pois depois de configurado, não será possível alterar

E na última tela ele irá mostrar uma revisão, basta finalizar e pronto! Seu novo CUR está configurado! Agora é necessário esperar pelo menos 24 horas para a AWS começar a enviar os dados para o seu bucket

2. Criando o Crawler e a tabela no Athena

Após os primeiros arquivos começarem a ser enviados, já conseguimos criar uma crawler para popular uma tabela Athena com os dados do billing

Gosto de utilizar o Athena para esse fim, porque se preciso extrair mais informações, sem a necessidade visual, escrevo as queries e executo direto no Athena

No serviço "AWS Glue", vá em "Crawlers" e "Add crawler", na primeira tela vamos definir o nome do nosso crawler

Depois vamos configurar o tipo, mas nessa tela podemos deixar o padrão mesmo

Agora vamos indicar onde está nossos arquivos de dados, ou seja, os dados do CUR que criamos no passo 1, onde basta indicar o bucket e a path onde os arquivos estão

A path geralmente será "{BUCKET}/awscur/{NOME DO BUCKET}/{NOME DO BUCKET}" (sim, ficou estranho, mas é o jeito que os arquivos são enviados hahaha)

Outra configuração é excluir algumas extensões no momento do scan, onde você pode adicionar essas aqui:

**.json **.yml **.sql **.csv **.gz **.zip

Na próxima tela, pode deixar a opção "No" selecionada, pois não vamos precisar de outro data store

Agora vamos configurar a role para execução do serviço, onde podemos criar uma nova sem problemas!

Na tela de frequência de execução, podemos configurar para executar diariamente, visto que o report completo do CUR geralmente é D-2 (hoje menos 2 dias)

Nesse momento, vamos configurar a database onde os dados serão enviados, e como não temos uma database, pode clicar em "Add database"

Na tela que irá abrir, preencha o nome da sua database, e o restante pode deixar o padrão mesmo

Após clicar em "Create", irá voltar para a tela da etapa 6, nessa tela expanda a configuração "Configuration options (optional)" e selecione a configuração "Delete tables and partitions from the data catalog"

A última tela irá fazer uma revisão das suas configurações, e caso esteja tudo OK, basta clicar em "Finish"

Pronto! Sua configuração está feita! Selecione o seu novo crawler criado e clique no botão "Run crawler" para fazermos a primeira execução dele, e caso tudo certo, será exibido que uma nova tabela foi adicionada!

3. Criando seu Cost and Usage Reports

A última etapa do processo é conectar essa nossa nova tabela do Athena no QuickSight, e para isso vamos acessar o serviço "QuickSight"

Nota: Caso seja a primeira vez que você entra no QuickSight, ele irá solicitar para criar um novo usuário. Recomendo visitar a página de custos do QuickSight para entender um pouco mais sobre os valores cobrados

Já no QuickSight, a primeira coisa que devemos fazer é configurar um novo Dataset apontando para a nossa tabela no Athena, então na tela principal clique em "Datasets" na lateral esquerda e em seguida em "New dataset"

Nas opções exibidas selecione "Athena", e irá abrir uma janela onde você deve colocar o nome do seu dataset, e após isso, só clicar em "Create data source"

Ele irá avançar para uma próxima tela onde irá exibir suas tabelas do Athena disponível, basta selecionar a database e tabela que criamos na etapa 2 e clicar em "Select"

Na próxima tela, você poderá utilizar o SPICE (armazenamento do próprio QuickSight) ou executar as queries direto (geralmente utilizo essa)

E pronto...nosso dataset está criado! Ele irá gerar uma análise já utilizando esse dataset novo, porém ainda temos que fazer mais uma liberação...

Na parte superior, clique no usuário e em "Manage QuickSight"

Quando abrir a tela, vá em "Security & permissions", e em "QuickSight access to AWS services" clique no botão "Manage"

Na tela que abrir, logo abaixo de "Amazon S3", clique em "Select S3 buckets" e no modal que será aberto, selecione o bucket criado na etapa 1

Pronto! Seu dataset está pronto e agora é só criar suas análises! Em próximos artigo vou mostrar algumas sugestões de dashboards voltados a custos na AWS e como cria-los!

Referencias

Custos do QuickSight: https://aws.amazon.com/quicksight/pricing/
Documentação QuickSight: https://aws.amazon.com/quicksight/
Documentação do Athena: https://aws.amazon.com/athena/
Documentação CUR: https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/
Cost Optimization no AWS Well-Architected Labs: https://www.wellarchitectedlabs.com/cost/

Até mais e muito obrigado pela Leitura! Ah, e se sentiu falta de alguma informação, algo que possa estar errado ou se quiser tirar dúvidas, fiquem a vontade de comentar! 😃

Mas afinal de "contas"...o que é FinOps?

Felipe KiKo — Fri, 16 Jul 2021 12:47:31 +0000

...sim, tentei fazer um trocadilho no título e admito...foi muito ruim!

Que o movimento Cloud trouxe inúmeros benefícios, isso podemos concordar com certeza! O que antes levava dias para subir um servidor e hospedar sua aplicação, com diversos processos de compras e entregas, hoje com menos de 10 cliques em um console web e um tempo menor que 10 minutos temos nossa aplicação publicada!

Maravilha né!? Nesse "boom", milhares de empresas migraram para a nuvem...mas, agora algumas estão voltando, e porque, se ganhamos velocidade, qualidade e autonomia?

Um ponto oculto no meio dessas qualidades é o custo...como que ele ficou? Uma das frases que mais escutei nesses últimos tempos foi que "A nuvem é cara", e fica a reflexão...é cara mesmo e/ ou precisa ser cara? Já digo que não!

Da mesma maneira que temos o DevOps que nos ajuda com as automações e entregas dos deploys das nossas aplicações de uma forma eficaz, rápida e com qualidade, temos o FinOps, que nos ajuda a entender e utilizar a Cloud de maneira também eficaz, evitando desperdícios e consequentemente mantendo os custos controlados, utilizando somente o que realmente é necessário utilizar

Mas, o que é o "FinOps"?

É um time? Uma ferramenta? Metodologia? Passáro? Avião???
Não não!! FinOps é C-U-L-T-U-R-A!

Parece meio clichê falar isso, mas é verdade! Não adianta ter um time focado em análise e redução de custos + diversas ferramentas para monitoramento e alertas, se o time que está atuando na ponta não tem consciência da utilização correta dos recursos...seria um círculo vicioso que só desgastaria ambos os times, onde de um lado o time de FinOps cobraria redução, e do outro, o time de desenvolvimento não saberia a melhor forma de otimizar seus custos

Um dos erros mais comuns quando falamos de FinOps é ter como único objetivo a redução do custo final da fatura, quando isso deveria ser a consequência de uma correta utilização da Cloud, não necessariamente "reduzindo" o valor da fatura. Quando colocamos esse tipo de meta ou algo similar, logo estaremos limitando a utilização de recursos Cloud, o que acaba barrando a sua adoção e suas principais vantagens...

Para ilustrar melhor o que disse, é muito diferente dizer "Vamos reduzir 2 mil mês que vem" do que "Vamos evitar perder 2 mil mês que vêm". Se invertemos e colocarmos como meta evitar o desperdício na Cloud, estaremos implicitamente adotando boas práticas, e como resultado disso evitando custos desnecessários, utilizando a nossa Cloud da maneira correta, onde será refletido também na fatura no final do mês!

Outro ponto...pode parecer um pouco radical e utopia, mas na minha visão, algo a ser percorrido é não existir um time centralizado de FinOps. Inicialmente sim, é necessário para definir alguns pilares e disseminar a cultura entre os times, porém conforme for ficando "enraizado" essa cultura, a missão do time exclusivo de FinOps foi concluída, e ao invés de um time centralizado, teremos diversos "evangelistas" da cultura dentro de todas as áreas, com seus próprios acompanhamentos de custos e boas práticas, orientado a sua arquitetura de solução

OK, então vamos montar um time!

Por mais que disse que a ideia é não existir um time de FinOps, em um primeiro momento é importante ter pessoas focadas somente nesse assunto, para não ter desvio de atividades e acabar deixando a parte financeira para ver somente quando a fatura chega

A ideia desse time, é conseguir extrair o máximo de eficiência de custos na Cloud, sempre com muita transparência, auxiliando sempre os times de produtos, fazendo com que eles concordem e entendam as iniciativas propostas...e não aquele time "chato" que só faz cobrança de valores na fatura, no estilo do Sr. Barriga cobrando toda vez o aluguel do Sr. Madruga

O time FinOps pode ser composto de várias áreas, partindo desde a diretoria (para aprovação de manobras de reservas e/ ou visão do roadmap orçamentário, por exemplo), analistas, arquitetos (para focar em questões de rightsizing e novas arquiteturas orientadas a melhor utilização da Cloud), pessoas mais técnicas (como desenvolvedores, para implementações de algumas automações) e até envolvendo outras áreas, como por exemplo o time de Finanças e RH, onde é possível até mudar a forma de contratação, colocando como um requisito desejável (ou obrigatório dependendo da empresa) essa mentalidade FinOps...é, hoje em dia não tem como escapar desse assunto!

Podemos colocar algumas atividades desse time como:

Evangelização da Cultura FinOps
Otimização de utilização de recursos Cloud
Negociação junto a fornecedores por descontos Alinhamento estratégico das aplicações VS custo (ROI)
Documentações dos processos de utilização correta da Cloud
Automatizações (tanto para o próprio time como para os outros)
Análise Financeira (relatórios para os executivos)
Disponibilização de alertas referente a custos
Análise de arquitetura de Solução / Infra com uma visão FinOps
"Antenados" em canais FinOps e nas novidades dos players de Cloud
Definições de estratégias de reduções de custo como reserva ou ambientes "spots"

Tá...mas como começo?

Depois de escolhido e montado seu time, é importante ter um norte, com metas e objetivos, onde alguns pilares podem ajudar nessa jornada

Deixei aqui os 3 pilares que na minha visão, acho essenciais para uma trilha FinOps de sucesso

1. Coleta de informações e definição de metas

E como toda longa jornada tem seu primeiro passo, e antes de reduzir ou até colocar algumas ações, precisamos ter dados e informações. Aqui entra as coletas e análises dos custos, onde vamos conseguir entender melhor nossa utilização da Cloud e onde o "mato está alto" nos custos

Após a coleta, o time de FinOps será responsável em apurar os dados, condensar e compartilhar com os times de produto ou as áreas interessadas, inclusive já mostrando uma forma inicial de como eles podem colaborar com essa coleta, como por exemplo, a estratégia de alocação correta de Tags

Com os dados coletados, apurados e feito uma conversa inicial com os times, mostrando seus resultados "quick wins" de reduções e identificando formas que eles podem ajudar para coletar com mais detalhes (ufaaa), podemos seguir em uma etapa opcional e fazer um confronto com o orçamento da empresa, onde o time de produto deverá ter a visão do valor disposto para utilização da Cloud, e em cima disso trabalhar constantemente revistando seus componentes, podendo até atrelar métricas de custo ou utilização consciente da nuvem junto com outras possíveis métricas existentes, como de performance e segurança

Esse trabalho é continuo, ou seja, sempre estaremos coletando novas informações e analisando, gerando novas métricas e até mesmo removendo métricas antigas, é um cenário muito dinâmico e é inevitável esses "ajustes de rota"...ou vai me dizer que sua aplicação do mês passado é a mesma de agora? Esses ajustes e análises são necessários inclusive para alinhamento de valor de negócio, para saber se sua aplicação continua rentável...ou se o molho ficou mais caro que o peixe

2. Mão na Massa! Automatização e ações

Abuse da criatividade no momento de operação e até na coleta de informações...automatize tudo! Por exemplo, podemos automatizar um alerta para o usuário, e até posteriormente remover componentes que estão com alguma subutilização ou utilização de maneira indevida, gerando custo desnecessários, como por exemplos discos "soltos" que não estão associados em nenhuma instância, ou aquela "servidorzinho" que você ligou ontem só para testar uma aplicação e acabou esquecendo ligado na sua conta

Em questão de ferramentas, existe diversas empresas que vendem ótimas ferramentas com esse propósito, os próprios players das nuvens estão evoluindo constantemente com dashboards e ferramentas relacionadas a custos. Já no mundo opensource, existe também algumas ferramentas e mecanismos que podem te ajudar nesse papel. Nesse outro artigo falo um pouco da ferramenta Cloud Custodian, em uma visão mais voltada para segurança, mas no meu GitHub adicionei algumas policies voltadas para o controle de FinOps. Fique a vontade para dar uma olhada e modificar para o cenário atual da sua empresa! ;)

Além disso, outras estratégias como a utilização de TAGs podem ser nossas aliadas para coletar e consolidar todo o custo...por isso é super importante uma boa gestão de TAGs no seu ambiente!

Mais para frente, vou dedicar um artigo exclusivo para falar de algumas automações no mundo de FinOps! (me cobre se eu esquecer!)

Indo para o lado de ações, ai não tem segredo...é olhar para a conta, analisar e verificar tudo que podemos executar para melhorar os custos, onde temos alguns bons aliados que acabam nos dando algumas pistas, como o Trusted Advisor da AWS...nele conseguimos ter um cenário mais "mastigado" de onde conseguimos já obter algumas reduções; Porém nenhuma dessas ações ou ferramentas dispensa aquela boa analisada na arquitetura de software VS arquitetura de infra, para tirar algumas ideias de como manter o mesmo comportamento da solução, mas de uma forma mais eficiente em questão de custos...esse é o desafio!

3. Cultura!

Esse é o pilar mais importante, mas pode ser o que mais teremos trabalho, pois mudar a cultura nunca foi fácil...mas uma boa forma de começar é mostrando para os times o quanto estão pagando pela sua infraestrutura e trazer alternativas para redução de custos, visto que já temos os dados obtidos e feito uma primeira análise deles

Além disso, existem outras forma de abordagem em um escopo mais amplo, disseminando para toda a empresa, como vídeos (mesmo que pílulas pequenas), documentação e eventos (que tal implementar algo relacionado com a FinOps com gamificação? Todo mundo adora brindes!), e para nos orientar qual tema devemos abordar, novamente os dados coletados vão dar dicas preciosas de "onde dóis mais" na questão de custo

Com o passar do tempo e uma cultura FinOps na empresa, os times passarão a ter a percepção de custo e adequar suas arquiteturas...será natural! Usando a nuvem não orientado a maneira mais barata, mas sim da maneira correta, onde a redução será consequência, e uma boa estratégia é sempre mostrar e deixar disponível os resultados obtidos, para motivar quem já está na jornada e incentivar quem está adotando

Com todos os dados coletados, ações feitas e times treinados, podemos agora criar relatórios, dashboards, alarmes (automação!), metas, KPIs, etc...a ideia é dar visibilidade para os times e para a empresa de como está nossa saúde financeira na Cloud, onde quanto maior a colaboração, menor será o índice de desperdício, lembrando novamente que nosso objetivo ainda não é somente financeiro, e sim a utilização correta da nuvem, fazendo valer a pena cada "doleta" gasto nos seus produtos!

E para encerrar...

Precisamos esclarecer uma coisa, dinheiro gasto não retorna para a carteira, o que podemos fazer é aprender como estamos gastando e melhorar isso

Com a maturidade do time e da metodologia, conseguimos usar a Cloud de uma maneira mais efetiva ainda com outras estratégias, por exemplo, tem medo de reservar instâncias? Não precisa ter!! Instâncias Spots? Não é tão "complicado" utilizar como o pessoal pensa...Em breve vou publicar outros artigos que entram mais no detalhe dessas duas abordagens super interessantes e que nos ajudam demais nesse controle de custos

E lembrando...todo esse fluxo e ações que falei aqui, são contínuas, onde devemos sempre medir, analisar e repetir, conseguindo sim deixar nossa Cloud muito mais efetiva e atrativa! O tema FinOps não tem regra e muito menos fim, o ideal é ter em mente seus conceitos e adequar da melhor maneira para o seu dia-dia...

...E quem sabe utilizar uma pequena parte das economias para um Happy Hour com todo o time? Afinal, eles merecem!! Cheers!

Até mais e muito obrigado pela Leitura! Ah, e se sentiu falta de alguma informação, algo que possa estar errado ou se quiser tirar dúvidas, fiquem a vontade de comentar! 😃

Referências

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

Felipe KiKo — Thu, 15 Jul 2021 14:51:12 +0000

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!

Referências

Cloud Custodian: Site oficial e documentação

Até mais e muito obrigado pela Leitura! Ah, e se sentiu falta de alguma informação, algo que possa estar errado ou se quiser tirar dúvidas, fiquem a vontade de comentar! 😃

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

Felipe KiKo — Thu, 15 Jul 2021 13:50:16 +0000

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 vou explicar um pouco o que é Guardrails e uma segunda parte mais técnica, explicando a ferramenta Cloud Custodian

Introdução

Ei! Como vocês estão nesses tempos difíceis que estamos passando? Você já está acostumado com a vida em casa, e SÓ em casa? Eu pelo menos falo que dia a dia estou aprendendo um pouco mais sobre como é estar no mesmo lugar o tempo todo, de uma forma mais "amigável" e até aproveitando um pouco da situação!

Como? Colocando alguns limites e barreiras...isso mesmo, não quer dizer que só porque estamos em casa podemos fazer tudo, principalmente quando temos várias reuniões durante o dia com crianças pequenas em casa!

E isso tem muito a ver com o que vamos falar aqui hoje...limites, ou também conhecidos como GuardRails (corrimão, trilho de segurança, etc.)!

Nos últimos dias, ouvi muito sobre esse termo "GuardRails" e, sinceramente, era um termo que não tinha muito a sua associação com tecnologia, muito menos na nuvem, mas depois que entendi, vejo que é essencial para a governança e a segurança correta para se trabalhar na nuvem, e é isso que quero compartilhar com vocês aqui, explorando um pouco mais sobre os conceitos e uma ferramenta que podemos usar para nos ajudar nessa jornada

Conceito

Hoje em dia, criar servidores ficou muito mais fácil e rápido, tudo por causa da nuvem, onde podemos criar um servidor com alguns cliques e em questão de minutos (quem dirá segundos), e isso trouxe grandes benefícios para todas as empresas que o utilizam, aumentando seu "Time To Market"

Mas junto com isso, trouxe alguns perigos, tanto em termos de segurança quanto de custos, onde você também pode aumentar seus custos com a mesma agilidade que um servidor será criado ou até mesmo terá seus arquivos expostos com apenas um clique em um console, então mais do que nunca é necessário falar sobre alguns limites

Sei que você pode estar pensando algo como: "Nossa, mas a agilidade que a nuvem trouxe para minha equipe, terei que retirar e definir limites, voltando ao que era antes?", e respondo que sim e não ao mesmo tempo!

É possível criar um catálogo de serviços que sua equipe possa usar ou não, porém pode ser um trabalho enorme e constante, já que as nuvens públicas lançam um novo serviço ou alteram eles o tempo todos e todos os dias (não na mesma proporção que novos frameworks são criados, mas é muito rápido também!), onde a equipe que mantém o gerenciamento da sua nuvem tem que "disponibilizar" produtos em nuvem para sua equipe, criando catálogos e produtos disponíveis, quase como "produtizar" os "produtos"

Tá, ok...mas o que podemos fazer então? Como podemos manter a equipe ágil trabalhando com sua nuvem favorita, mas também sem trazer riscos para o s eu negócio? Uma solução é aplicar GuardRails! Isso mesmo, coloque um limite sem "produtizar" produtos

Para explicar melhor, imagine que você leva sua filha de 8 anos para jogar boliche...jogar boliche acaba sendo mais fácil para você, porque você sabe como funciona o jogo e seu objetivo, sabe lidar com o peso da bola e como jogá-la, e mesmo que de uma forma desajeitada, você atinge os pinos (pelo menos boa parte das vezes)...mas do outro lado, é mesmo jogo, objetivos e a mesma bola que sua filha terá que enfrentar, então ela não tem tanta força como você, e aquela bola grande e pesada é muito desajeitada para sua mãozinha...sua força e pontaria dependem muito mais de um empurrão e improvisação, onde na maioria das vezes a bola passa pela valeta, não alcançando os pinos (seu objetivo) e frustrando ela, deixando a impressão que aquele jogo é muito chato

Então, como resolvemos isso? Guardrails! Subimos pelas valetas laterais as canaletas! E o que conseguimos? Um experiência totalmente diferente, onde agora ela pode atingir seu objetivo, mesmo que encoste na lateral, a bola é sempre colocada novamente no seu curso, e finalmente acertar os pinos! E quem sabe até conseguimos um sorriso com um strike!

Esse é o objetivo, não nos privarmos de jogar o jogo como deveria ser, e os GuardRails da nuvem funcionam da mesma forma, ou seja, vamos deixar nossa equipe de desenvolvimento usar seus recursos favoritos de sua nuvem pública favorita! Vamos apenas "Levantar as canaletas" para evitar qualquer desvio indesejável

Um exemplo prático...você pode liberar com segurança o uso de Buckets S3 da AWS para sua equipe, mas preocupado com a segurança, você coloca algumas limitações para, por exemplo, não deixar o bucket público, evitando o possível vazamento de dados

Outro exemplo, você pode deixar seu time criar instâncias EC2 em sua conta de desenvolvimento, mas vamos permitir apenas no máximo 5 instâncias e na família "T3", evitando criar um grande quantidade de servidores e/ou máquinas grandes e caras, economizando alguns bons dólares para nossa empresa

Ferramenta

Nativamente, os grandes players de cloud pública têm seus serviços "Guardrails", cada um implementando da melhor maneira, por exemplo, na AWS temos meios para fazer isso juntando serviços como CloudTrail, EventBridge e AWS Config, ou até mesmo implementando o AWS Budget Actions...mas temos também outras ferramentas no mercado que têm uma abordagem mais "multi-cloud", e no próximo post vou explicar um pouco melhor a ferramenta open source, nosso amigo Cloud Custodian!