DEV Community

Luiz Bernardo for AWS Community Builders

Posted on • Edited on

Gerenciando políticas do AWS Organizations

Beleza, passamos por uns 3 posts ate chegar aqui. E aqui que todos os outros faz mais sentido 😁

A base das políticas do AWS Organizations são as políticas de controle de serviços (Service control policies), SCP, são aplicadas na conta e não existe hierarquia de SCP. Única ressalva e a respeito do Deny, caso algum serviço tenha uma SCP de deny esse serviço não poderá ser acessado mesmo que tenha uma allow explicita em alguma outra SCP.

Para construir uma políticas no Organizations com Terraform e bem simples, apenas precisa chamar o recurso e escrever o bloco content em json.

resource "aws_organizations_policy" "engenharia" {

  content = <<CONTENT
{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "*",
    "Resource": "*"
  }
}
CONTENT
}
Enter fullscreen mode Exit fullscreen mode

Alguns exemplos de SCP aqui

Um ponto aqui que acho importante e a sintaxe do content. Ela é composta por elemento, proposito e efeitos suportados.

Segue a tabelinha:

sintaxe SCP

Tem alguma politicas que gosto de recomendar para quem está se aventurando aqui.

Não permitir que uma conta saia da organização.

resource "aws_organizations_policy" "engenharia" {

  content = <<CONTENT
{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Deny",
        "Action": "organizations:LeaveOrganization",
        "Resource": "*"
    }
}

CONTENT
}
Enter fullscreen mode Exit fullscreen mode

Restringir serviços não globais em região especifica

resource "aws_organizations_policy" "engenharia" {

  content = <<CONTENT
{
  "Version": "2012-10-17",
  "Statement": [
      {
          "Sid": "RestrictRegion",
          "Effect": "Deny",
          "NotAction": [
              "a4b:*",
              "budgets:*",
              "ce:*",
              "chime:*",
              "cloudfront:*",
              "cur:*",
              "globalaccelerator:*",
              "health:*",
              "iam:*",
              "importexport:*",
              "mobileanalytics:*",
              "organizations:*",
              "route53:*",
              "route53domains:*"
              "shield:*",
              "support:*",
              "trustedadvisor:*",
              "waf:*",
              "wellarchitected:*"
          ],
          "Resource": "*",
          "Condition": {
              "StringNotEquals": {
                  "aws:RequestedRegion": [
                      "sa-east-1"

                            ]
          }
      }
  }
}
CONTENT
}
Enter fullscreen mode Exit fullscreen mode

Negar possibilidade de interromper o CloudWatch

resource "aws_organizations_policy" "engenharia" {

  content = <<CONTENT
{
 "Version": "2012-10-17",
    "Statement": {
        "Effect": "Deny",
        "Action": "organizations:LeaveOrganization",
        "Resource": "*"
  }
}
CONTENT
}
Enter fullscreen mode Exit fullscreen mode

#vlwflw

Sentry image

Hands-on debugging session: instrument, monitor, and fix

Join Lazar for a hands-on session where you’ll build it, break it, debug it, and fix it. You’ll set up Sentry, track errors, use Session Replay and Tracing, and leverage some good ol’ AI to find and fix issues fast.

RSVP here →

Top comments (0)

Best Practices for Running  Container WordPress on AWS (ECS, EFS, RDS, ELB) using CDK cover image

Best Practices for Running Container WordPress on AWS (ECS, EFS, RDS, ELB) using CDK

This post discusses the process of migrating a growing WordPress eShop business to AWS using AWS CDK for an easily scalable, high availability architecture. The detailed structure encompasses several pillars: Compute, Storage, Database, Cache, CDN, DNS, Security, and Backup.

Read full post