Forem: Kelly Lima

IAM Identity Center com Terraform

Kelly Lima — Sat, 27 Jan 2024 02:20:54 +0000

Recentemente tive um projeto no trabalho envolvendo o Identity Center da AWS (sucessor do Single Sign-On), quis deixar aqui de uma forma mais simples e prática coisas que fui aprendendo.

Para ficar um pouco melhor a visualização do que será feito, elaborei a imagem abaixo:

Falando das etapas:

Criação de um grupo;
Adicionar membro ao grupo;
Criação da Permission Set;
Adicionar policies na Permission Set;
Criar o que é chamado Account Assignment;

Algumas explicações básicas:

Permission Set é a forma que o Identity Center trabalha com permissões, por trás nada mais é que uma role que é atribuída à um grupo/usuário;
Esse processo que chamamos de Account Assignment nada mais é que criar o vínculo da Permission Set com a conta que você quer (por exemplo, conta de produção, desenvolvimento, etc). Caso você não conheça muito sobre a estrutura do Identity Center, de forma resumida, ele é centralizado, ou seja, todas as minhas permissões para todas as minhas contas irão ficar centralizada em uma conta só dentro do Identity Center, por isso precisamos criar esse vínculo para que ele saiba em qual conta essas permissões se aplicam.

Código

Tentei trazer um exemplo de código que possa ser reutilizado, para ficar um pouco mais elaborado e vocês conseguirem visualizar algo a mais e não ser um exemplo tão simples.

OBS 01: Estou considerando que você já tenha conhecimento de AWS e Terraform, logo suas credenciais/região já devem estar configuradas.
OBS 02: O código só funciona com a versão do provider AWS >= 5.14. Explico melhor sobre no final.

Nós teremos um arquivo de locals chamado local.tf que terá:


data "aws_ssoadmin_instances" "my_sso" {}

output "arns" {
  value = tolist(data.aws_ssoadmin_instances.my_sso.arns)[0]
}

output "identity_store_id" {
  value = tolist(data.aws_ssoadmin_instances.my_sso.identity_store_ids)[0]
}

# sempre vamos acabar precisando utilizar esse id e esse arn em outros lugares
locals {
  identity_store_id  = tolist(data.aws_ssoadmin_instances.my_sso.identity_store_ids)[0]
  identity_store_arn = tolist(data.aws_ssoadmin_instances.my_sso.arns)[0]
}

Nós teremos um outro arquivo chamado user-group.tf, nesse arquivo nós iremos colocar um exemplo de estrutura de usuários que queremos adicionar:


variable "user_group" {
  description = "Create users in Identity Center"
  default = {
    "kelly.lima" = {
      email      = "kelly.lima@email.com"
      group      = ["group-a"]
      first_name = "Kelly"
      last_name  = "Lima"
    }
  }
}

Um arquivo chamado policies-managed.tf onde colocaremos policies gerenciadas pela AWS a forma de adicioná-las é diferente das policies personalizadas. Nas gerenciadas nós teremos:


variable "policies_managed" {
  description = "Policies Managed (AWS)"
  type        = list(string)
  default = [
    "arn:aws:iam::aws:policy/ReadOnlyAccess",
    "arn:aws:iam::aws:policy/AWSBillingReadOnlyAccess"
  ]
}

Esses valores de arn serão padrão. Você pode pegar esses valores dentro do próprio IAM.

Arquivo de policies personalizadas se chamará policies-custom.tf e terá:


variable "policy_group_a" {
  description = "Policies Custom"
  type        = list(string)
  default = [
    "policies-group-a",
    "policies-default"
  ]
}

No exemplo acima, podemos ver que no Identity Center as policies customizadas nós devemos passar o nome, pois o resource aws_ssoadmin_customer_managed_policy_attachment (que iremos utilizar em breve) ele só aceita nome da policy e não o arn. Nesse caso eu estou considerando que essa policy já foi criada utilizando o resource aws_iam_policy.

Teremos um arquivo que chamaremos de accounts.tf onde terá:


variable "accounts_aws" {
  description = "Accounts AWS"
  default = {
    "prod" = {
      number = "123456789345"
    },
    "dev" = {
      number = "458456789345"
    }
  }
}

Este é um exemplo de como poderia ficar várias contas, mas nós iremos considerar apenas a conta "prod" para facilitar.

Agora nós teremos o nosso último arquivo onde iremos construir todo esse processo que temos na imagem do começo, ficaria:


# Criação do Group A
resource "aws_identitystore_group" "group_a" {
  identity_store_id = local.identity_store_id
  display_name      = "group-a"
  description       = "sso group a"
}

# Adciona os membros baseado no group em var.user_group
resource "aws_identitystore_group_membership" "membership_group_a" {
  for_each          = { for user in local.group_members : user => aws_identitystore_user.user_sso[user].user_id }
  depends_on        = [aws_identitystore_user.user_sso]
  identity_store_id = local.identity_store_id
  group_id          = aws_identitystore_group.group_a.group_id
  member_id         = each.value
}

# Criação da Permission Set
resource "aws_ssoadmin_permission_set" "permission_set_group_a" {
  name         = "PermissionGroupA"
  instance_arn = local.identity_store_arn
  description  = "Permission Set Custom"
}

# Adiciona as policies managed AWS na Permission Set
resource "aws_ssoadmin_managed_policy_attachment" "policy_managed_group_a" {
  instance_arn       = local.identity_store_arn
  count              = length(var.policies_managed)
  managed_policy_arn = var.policies_managed[count.index]
  permission_set_arn = aws_ssoadmin_permission_set.permission_set_group_a.arn
}

# Adiciona as policies customizadas na Permission Set
resource "aws_ssoadmin_customer_managed_policy_attachment" "policy_custom" {
  for_each = {
    for policy_key, policy_value in var.policy_group_a :
    policy_key => var.policy_group_a[policy_key]
  }
  instance_arn       = local.identity_store_arn
  permission_set_arn = aws_ssoadmin_permission_set.permission_set_group_a.arn
  customer_managed_policy_reference {
    name = each.value
    path = "/"
  }
}

# Adiciona a Permission Set com o Group A à conta "prod"
resource "aws_ssoadmin_account_assignment" "prod_env" {
  for_each = {
    for key, key_value in local.permission_set_arns :
    value_key => local.permission_set_arns[value_key]
  }
  instance_arn       = local.identity_store_arn
  permission_set_arn = each.value

  principal_id   = aws_identitystore_group.group_a.group_id
  principal_type = "GROUP"

  target_id   = var.accounts_aws["prod"].number
  target_type = "AWS_ACCOUNT"
}

locals {
# Aqui você pode colocar outros arns de Permission Sets
  permission_set_arns = [aws_ssoadmin_permission_set.permission_set_group_a.arn]

# Deixei esse locals no mesmo arquivo e não no arquivo local.tf apenas para questão didática, ficar mais prático de visualizar
  group_members = [
    for user, details in var.user_group :
    user if contains(details.group, "group-a")
  ]
}

Alguns pontos:

Como podem ver é utilizado o depends_on no resource aws_identitystore_group_membership foi colocado pois o código estava dando um bug na hora do apply, o Terraform reclamava de adicionar um membro que não existia ainda. Há outros problemas similares quando rodamos o destroy envolvendo Permission Sets, em alguns casos ele reclama do estado que está recebendo (espera estado A e recebe B), ao rodar o comando novamente ele consegue finalizar a exclusão do resource, é realmente um bug nos states do Terraform. Tentei utilizar o depends_on nesse caso também, mas não obtive sucesso, você pode ver melhor sobre nesses links:

Sobre o aviso que deixo acima da versão ser >= 5.14 é por conta desses bugs, antes da versão 5.14 eles ocorriam com maior frequência, houve várias correções referentes a Permission Set.

Conclusão

Bom, eu tentei ser o mais sucinta possível, espero que tenha ajudado, qualquer coisa só perguntar. Valeu! ✌️

Se preparando para a certificação AWS Solution Architect Associate (SAA-C03)

Kelly Lima — Mon, 08 May 2023 20:27:15 +0000

Recentemente passei na certificação AWS Solution Architect Associate (SAA-C03) e decidi compartilhar aqui quais foram os passos que tomei nessa saga.

Bom, começo avisando que trabalho com Cloud AWS há 2 anos, mas o meu contato maior foi no último ano.
Eu sei que é possível tirar sem nenhuma experiência mas a própria AWS recomenda pelo menos 1 ano de contato com AWS para realizar.

A Saga

Levei quase 6 meses de estudo, porque eu estudava uma hora por dia, alguns dias menos, alguns dias mais, eu realmente decidi fazer no meu tempo pois queria aproveitar o aprendizado também, além disso estava tendo uma mentoria por um colega do trabalho, o que foi muito bom para tirar algumas dúvidas.

Eu utilizei para estudo o curso do Stephane Maarek, na Udemy. Este curso é realmente bom e com preço acessível ~~na promoção~~, foi o meu maior guia nessa saga, após a finalização do curso eu passei para os simulados, foi ai que entrou as minhas maiores dúvidas.

Fiquei um mês fazendo simulados, fiz simulados do Jon Bonso, Neal Davis e os do Whizlabs.
No caso do Jon Bonso e do Neal Davis, eles são da Udemy, são 6 simulados cada.
Já do WhizLabs são 6 simulados mais 12 simulados menores em assuntos específicos como RDS, EBS, SQS e outros. Além disso, no final eles deixam mais um simulado que seria um Final Test.

Bom, desses três os que eu achei mais parecido com a prova foram os do Neal Davis e do Whizlabs.

Os do Jon Bonso são muito bons para aprendizado, eles são mais difíceis, as questões são mais longas e complexas, então acho que vale a pena para aprender, mas não levaria ele como base pois pode acabar dando uma desanimada com os resultados dos simulados, digo isso porque foram os primeiros que fiz e eu reprovei em 5 dos 6 de primeira. Acertava em média 65%, e no último acertei 73%. Na segunda vez eu acertei 90% pra cima em todos.

Já nos do Neal Davis eu passei de primeira em 5 dos 6. Acertei em média 80% e no último acertei 69%. Não fiz esses novamente, eu apenas estudei o que errei.

Lá vamos nós para mais simulados, fui para os do WhizLabs, na primeira vez eu reprovei em 3 e passei em 3. Na WhizLabs para passar é mais exigente pede 80%, já na Udemy é 72%. Na WhizLabs os que eu reprovei de primeira eu acertei em média 68%, nos que passei eu acertei 89%. Na segunda vez eu acertei uma média de 98%.

Quando eu estava fazendo os simulados foi onde surgiu a minha maior dúvida: Como saber se estou pronta pra prova? Afinal, se estou reprovando em simulado de primeira, como vou fazer a prova? E se esse simulado fosse a minha prova? Bom, vamos lá.

Primeira coisa que notei:
Os simulados que reprovei de primeira normalmente eles estavam focados em Networking (VCP, VPN, Transit Gateway e etc) e esse é um tema que tenho dificuldade, estudo ~~insisto~~ bastante mas ainda sim sei que é algo que posso melhorar.

Segunda coisa que notei:
Alguns simulados tem questões com serviços que não foram abordados a fundo no curso ou até mesmo comentado, foram pouquíssimas questões, mas foi interessante para conhecer e estudar, ai que entra a documentação da AWS, principalmente a parte de FAQ dos serviços, isso ajuda muito nos estudos.

Terceira coisa que notei:
Cheguei a conclusão de que se você estiver passando de primeira com uns 80%, dá pra fazer a prova já. Prova não é fácil, mas teve simulados que achei mais difícil que a prova.

A temida prova

A prova possui 65 questões dividida entre múltipla escolha e resposta múltipla (mais de 1 alternativa correta).

A prova que fiz abordou muito banco de dados (RDS, Aurora e DynamoDB), teve muitas questões envolvendo desacoplar serviços, logo, utilização de SNS, SQS, Kinesis. Questões de S3, envolvendo Lifecycle. Esses foram os tópicos mais abordados. Questão de Networking tiveram apenas 2 (que me recordo agora), poucas questões sobre KMS, Secrets Manager. No geral, são esses assuntos que me recordo.

Deixo como dica: Estude questões de custo, teve muitas questões que o cenário envolvia onde se teria menos custo, logo tinha algumas pegadinhas, pois as vezes uma alternativa parece correta, porém ela é mais cara. Por exemplo, de forma resumida, teve uma questão que falava sobre Alta Disponibilidade de Banco de Dados mas o principal era o custo, e uma das alternativas falava do Aurora, porém havia outra que falava sobre RDS, que é mais barato no cenário da questão, então é importante estar atento.

Importante: O resultado da prova não sai na hora, leva em média 24hrs. No meu caso levou 23hrs para sair o resultado. Sim, aguenta coração que a ansiedade bate.

No final, eu tirei 871 na prova. Eu sai da prova com sentimento misto, algumas questões eu sabia, outras fiquei em dúvida entre 2 alternativas, imagino que é normal sair com sentimento de preocupação.

Enfim, espero que isso ajude alguém tentei trazer pontos que não encontrei em outros artigos e era a minha dúvida, fico a disposição para tirar dúvidas sobre e boa sorte! 🤘

Pipeline Prowler

Kelly Lima — Sun, 19 Feb 2023 02:38:46 +0000

Antes de tudo, gostaria de dizer o que me motivou a criar esse artigo/tutorial, bom, sou nova na área de segurança e percebi que tenho muita dificuldade em encontrar artigos/tutoriais em português, em específico de Cloud, vejo muito o básico da teoria sendo explicado, mas vejo pouca prática, então decidi unir o útil ao agradável, passar os conhecimentos que tenho (são poucos e talvez não tão bem definidos) mas espero que possa ajudar alguém e também me ajudar, pois escrevendo para outras pessoas preciso conhecer melhor ainda o assunto o que me faz estudar mais ainda. 💙

Mas o que é o Prowler?

Prowler é uma ferramenta open-source de segurança, neste caso, voltado para segurança Cloud, em específico AWS. Ele funciona como um scan, scanea o seu ambiente baseado em diversos padrões de controle, um exemplo seria o CIS. Dei um resumo do resumo sobre, você pode ver melhor sobre ele aqui.

No desenvolvimento dessa pipeline eu quebrei muito a cabeça, primeiro por não conhecer Jenkins (quem dirá Jenkinsfile) e entender o conceito do Prowler mas não ter visto em prática, no final ela ficou bem mais simples, mas acredite, para alguém que só conhecia e mexia com Angular, foi um desafio legal.

Agora vamos lá, de forma resumida nós iremos criar um Jenkinsfile e trabalhar com imagem Docker do Prowler dentro. O Prowler já possui uma imagem feita e já possui diversos parâmetros que podemos passar, o que facilita bastante o desenvolvimento, de forma resumida nós teremos duas grandes etapas:

Dar pull na imagem Docker do Prowler;
Executar o scan.

OBS: Fiz esse tutorial para pessoas que conheçam o básico de Jenkinsfile/estrutura, assim como de AWS (Access Keys).

Vamos lá, primeiro que iremos subir essa pipeline através de um arquivo Jenkinsfile e ele no final ficará assim:

Simples, não? Bom, agora vou explicar um pouquinho cada stage que temos:

Primeiro stage chamado: Pipeline Info é apenas visual, eu gosto de ter um primeiro stage apenas para retornar que está inicializando, para mim deixa a usabilidade melhor, mas caso você não queira, pode ignorar.
Segundo stage chamado: Setting up Prowler container é onde fazemos um docker pull da imagem do Prowler, como comentei, Prowler já possui uma imagem própria configurada dentro do Docker Hub, pode ver melhor aqui.
Terceiro stage chamado Setting up envs AWS and run Prowler, é onde a magia toda acontece e tenho alguns pontos para colocar sobre, primeiro:

Nos steps nós temos um comando withAWS, mas o que é isso? Bom, withAWS é um comando que vem do plugin Pipeline: AWS Steps, você pode ver melhor sobre aqui, bom esse comando em específico é para setar uma "autorização" para os próximos passos, ou seja, uma credencial diretamente, uma role, um profile. No exemplo acima nós estamos passando uma role, e as permissões que essa role precisa ter, você pode encontrar aqui no Github do projeto.
Após passarmos as credenciais que serão usadas, nós iremos passar um script, com alguns pontos que vamos abordar por partes, primeiro, vamos imaginar que iremos passar o comando docker run sem estar dentro de um script, ele irá ficar assim:

Vamos falar um pouco sobre cada parâmetro que estamos passando:

--rm        | para remover nosso _container_ após a execução
--name      | é onde passamos o nome do nosso container
--env       | são variáveis de ambiente para pegar os valores das nossas credenciais da AWS para poder executar o scan

Esses são os parâmetros mínimos que precisam ser passados para executar o Prowler, e você pode ver melhor sobre na documentação aqui.
Agora vamos falar dos outros:

-f        | para filtrarmos por uma região específica
-M        | caso queiramos salvar o resultado do nosso scan, é com esse parâmetro que escolhemos o formato do resultado, pode ser HTML, Json e outros, no exemplo estamos selecionando HTML 
-B        | para salvar o nosso resultado em um Bucket S3 nós podemos passar esse parâmetro com nome do mesmo

Algumas observações, o output no formato HTML é muito útil, similar a um dashboard e podemos filtrar por serviço, controle, o que deu falha ou sucesso, sem contar que conta com outras informações como um score que você pode utilizar para ter uma base da saúde do seu ambiente.
Uma outra observação, estamos sempre utilizando a última versão da imagem lançada e não uma fixa, está desse jeito para fins didáticos, mas eu recomendo que em um ambiente produtivo seja definido uma versão específica para evitar problemas de compatibilidade no futuro.

Vamos voltar para o nosso código completo? No nosso código completo o último stage fica:

Por que executamos desse jeito com o nosso comando docker run em volta de um script e não diretamente igual no exemplo acima que usamos para explicar os comandos? Na verdade, nós podemos executar igual está acima, sem ter um script em volta e ele irá executar todo o comando, mas teremos um problema no retorno do Jenkins. Nossa pipeline irá retornar como Failure mesmo tendo executado tudo da forma correta, pois o Jenkins irá retornar exit code 3, como mostro abaixo:

Aparentemente quando se executa um Shell Script no Jenkins, tudo que for diferente de 0 (que é sucesso) ele irá lançar um erro de exceção e "quebrar" a pipeline, então nós devemos tratar esse retorno, nós tratamos exatamente na parte que colocamos o returnStatus: true, podemos ver melhor aqui na documentação do Jenkins sobre esse parâmetro para Shell Scripts.

Admito que levei algumas horas de pesquisa e ainda não compreendi a fundo o porque de ele retornar exit code 3, mas descobri que não é algo incomum o Jenkins retornar erros e as pessoas tratarem dessa forma por se tratar de um falso positivo. Também dá para tratar erros específicos utilizando if/else.

Peguei essa dica aqui.

Uma observação, para fins didáticos nós deixamos para ele sempre retornar sucesso, por sabermos que se trata de um falso positivo, mas em um cenário produtivo eu recomendo tratar o erro em específico (exitCode == 3) e pensando em outros erros para retornar algum aviso/ação.

Bom, é isso pessoal! Espero que esse tutorial ajude alguém 💙