Como estruturar sua empresa no Google Cloud Platform

• Garanta o alinhamento organizacional
• Escolha sua própria aventura
• Configure a identidade com grupos de usuários / papéis
• Centralize suas redes com Shared VPCs
• Planeje todos os seus recursos
• Use tags nos recursos para ter relatórios melhores
• Configure alertas de orçamento
• Organize seus repositórios de código-fonte para IaC
• Configure alertas de segurança / monitoramento
• Use um Bastion (Jump) Host
• Proteja seus dados
• Use o Cloud Security Command Center
• Documente e teste seus planos de recuperação de desastres e continuidade de negócios
• Tenha como parceiros especialistas que já fizeram isso antes

Embora este artigo foque em recursos do Google Cloud Platform (GCP), seria injusto não dar o crédito ao CEO da AWS, Andy Jassy, por resumir com elegância quatro chaves para o sucesso de uma transformação de nuvem — e arrisco dizer, para o sucesso de qualquer iniciativa:

1. Convicção e alinhamento da liderança sênior
2. Metas ambiciosas, vindas de cima para baixo
3. Capacite seus builders
4. Não deixe a paralisia [da análise] te travar antes mesmo de começar

Meu mantra pessoal ao experimentar coisas novas é: "primeiro faça funcionar, depois faça direito, depois faça rápido".

O Google tem ótimos materiais online sobre boas práticas para empresas, e a ilustração abaixo mostra os passos recomendados para Secure Google Cloud Services. Cada organização tem necessidades diferentes, então este roteiro é um excelente ponto de partida para planejar sua infraestrutura ou conhecer o que está disponível.

Fonte: Google

Comece com uma política de menor privilégio e desabilite imediatamente a criação de projetos no nível da organização. Apenas DevOps, Billing e OrgAdmins devem ter essa permissão e, idealmente, só uma service account em DevOps para a automação de infraestrutura (ou seja, Terraform). Sempre que possível, não adicione pessoas individualmente ao seu IAM.

• Organization Administrators ([email protected])
• Network Administrators ([email protected])
• Security Administrators ([email protected])
• Billing Administrators ([email protected])
• DevOps ([email protected])
• Development ([email protected])
• DataScience ([email protected]) [opcional]

Depois de criar esses grupos — opcionalmente com o Cloud Identity (conectando ao seu AD ou IdP existente) ou na sua organização do GSuite —, adicione pelo menos uma pessoa por grupo. Em seguida, atribua os papéis necessários somente quando preciso a cada grupo, no nível da Organização ou da Pasta.

Fonte: Google

Se você adota GitOps, os times de desenvolvimento podem implantar quaisquer workloads* em seus respectivos namespaces de cluster Kubernetes via pipelines de CI/CD a partir do controle de versão. Essa abordagem ajuda a gerenciar acesso e cotas, facilitando o controle de custos e o orçamento na nuvem.

*apenas binários aprovados de um repositório de imagens privado e confiável

Em setores altamente regulados ou ao manter conformidade com normas como SOC 2, seus controles podem exigir uma rigorosa separação de responsabilidades. Uma prática comum nas empresas é separar a gestão de rede do DevOps e do desenvolvimento de aplicações. O GCP facilita isso com a shared VPC e a elegante hierarquia de projetos — host e service projects.

Projete e planeje sua rede para evitar colisões e apague todas as redes padrão dentro dos projetos — você vai me agradecer depois!

Como mencionei, esta é uma abordagem opinativa, mas a sua pode ser diferente. Minha recomendação é encapsular seus service projects em um host project e centralizar a configuração de rede em um único lugar, dando acesso a esses projetos somente ao grupo de network administrators.

Ao alocar IPs para suas sub-redes, dependendo da escala e dos planos de crescimento, uma faixa CIDR /16 para uma VPC já é mais que suficiente (65.000 endereços). O Kubernetes, no entanto, exige um grande número de IPs para services e pods, já que eles recebem IPs dinamicamente para containers efêmeros. Sugiro reservar uma faixa adicional não utilizada para IPs secundários, como abaixo:

• sub-rede dentro da faixa /16 da VPC: k8s-nodes-prod (10.10.0.0/22)

secundária: k8s-services-prod (10.80.64.0/22)

secundária: k8s-pods-prod (10.80.0.0/18)

sub-rede: bastion-prod (10.10.64.0/29)

• sub-rede dentro da faixa /16 da VPC: k8s-nodes-stage (10.11.0.0/22)

secundária: k8s-services-stage (10.81.64.0/22)

secundária: k8s-pods-stage (10.81.0.0/18)

sub-rede: bastion-stage (10.11.64.0/29)

• sub-rede dentro da faixa /16 da VPC: k8s-nodes-demo (10.12.0.0/22)

secundária: k8s-services-demo (10.82.64.0/22)

secundária: k8s-pods-demo (10.82.0.0/18)

sub-rede: bastion-demo (10.12.64.0/29)

• sub-rede dentro da faixa /16 da VPC: k8s-nodes-qa (10.13.0.0/22)

secundária: k8s-services-qa (10.83.64.0/22)

secundária: k8s-pods-qa (10.83.0.0/18)

sub-rede: bastion-qa (10.13.64.0/29)

• sub-rede dentro da faixa /16 da VPC: k8s-nodes-dev (10.14.0.0/22)

secundária: k8s-services-dev (10.84.64.0/22)

secundária: k8s-pods-dev (10.84.0.0/18)

sub-rede: bastion-dev (10.14.64.0/29)

Isso deixa bastante espaço dentro da sua VPC para sub-redes adicionais voltadas a servidores de banco de dados ou outros recursos.

O Google Cloud Platform organiza recursos por organização, pasta e projeto. Isso facilita a gestão de usuários e grupos, sem a loucura de múltiplas contas de outras plataformas. Muitas empresas que adotaram a nuvem cedo acabaram presas construindo soluções customizadas para administrar essa "bagunça" de contas e permissões — um pesadelo para InfoSec e compliance. O GCP acertou nesse ponto.

├── DevOps
│   └── project-devops
│       ├── bucket-terraform-state
│       ├── cluster-devops
│       │   ├── namespace-cicd
│       │   └── namespace-vault
│       ├── sink-application-logs
│       └── sink-audit-logs
├── RnD
│   ├── Non-Production
│   │   └── project-shared-network-nonprod
│   │       ├── sink-application-logs
│   │       ├── sink-audit-logs
│   │       ├── vpc-demo-10-12-0-0
│   │       │   └── project-demo
│   │       │       ├── cluster-demo
│   │       │       │   ├── namespace-team1
│   │       │       │   ├── namespace-team2
│   │       │       │   └── namespace-vault
│   │       │       ├── sink-application-logs
│   │       │       └── sink-audit-logs
│   │       ├── vpc-dev-10-14-0-0
│   │       │   └── project-development
│   │       │       ├── cluster-development
│   │       │       │   ├── namespace-team1
│   │       │       │   ├── namespace-team2
│   │       │       │   └── namespace-vault
│   │       │       ├── sink-application-logs
│   │       │       └── sink-audit-logs
│   │       └── vpc-qa-10-13-0-0
│   │           └── project-development
│   │               └── cluster-qa
│   │                   ├── namespace-team1
│   │                   ├── namespace-team2
│   │                   └── namespace-vault
│   ├── Production
│   │   └── project-shared-network-prod
│   │       ├── sink-application-logs
│   │       ├── sink-audit-logs
│   │       ├── vpc-prod-10-10-0-0
│   │       │   └── project-production
│   │       │       ├── cluster-production
│   │       │       │   ├── namespace-team1
│   │       │       │   ├── namespace-team2
│   │       │       │   └── namespace-vault
│   │       │       ├── sink-application-logs
│   │       │       └── sink-audit-logs
│   │       └── vpc-stage-10-11-0-0
│   │           └── project-stage
│   │               ├── cluster-stage
│   │               │   ├── namespace-team1
│   │               │   ├── namespace-team2
│   │               │   └── namespace-vault
│   │               ├── sink-application-logs
│   │               └── sink-audit-logs
│   └── project-monitoring
│       ├── bucket-development-logs
│       ├── bucket-production-logs
│       ├── workspace-development
│       └── workspace-production
└── Security
    └── project-security
        └── bucket-audit-logs

Um dos desafios mais comuns — e fontes de confusão — em nuvens públicas é o billing, os relatórios e o controle de custos. Uma forma de gerenciar custos é desenhar a infraestrutura com namespaces por time, como mostrei acima. Isso acelera o onboarding e a produtividade do time de desenvolvimento, evitando uma curva de aprendizado íngreme ou um pool de talentos restrito. Outra boa prática é etiquetar (tags/labels) os recursos para depois criar alertas, orçamentos e relatórios.

Um colega meu escreveu este artigo sobre "Auto Tagging Google Cloud Resources", usando nossa ferramenta open source, IRIS. Há vários outros bons artigos sobre o tema, então planeje suas tags com antecedência e evite dor de cabeça depois.

Tags sugeridas por recurso:

• Owner — quem é o responsável atual (pode ter mudado de time)
• Creator — quem criou originalmente (pode tirar dúvidas depois)
• Project — ex.: my-company-production, para um agrupamento melhor
• Working Hours — economize até 60% agendando recursos de dev automaticamente com o Zorya

Muitos CFOs ainda têm receio da nuvem por causa da falta de visibilidade e do risco de gastos sem fim por uma configuração errada. Com os budget alerts, dá para acompanhar o gasto diário e reagir rápido para alinhar o gasto na nuvem com a receita da empresa. Vale disponibilizar as informações de custo aos times e cobrar dos líderes que se reúnam regularmente para acompanhar o orçamento.

Quando você já tem o plano da hierarquia de recursos, surge um dilema do ovo e da galinha. Você provisiona tudo com Terraform — e, se sim, como o Terraform consegue as permissões para criar tudo? A sugestão é que o Org Admin crie a pasta e o projeto de DevOps, e o time de DevOps crie uma Service Account do Terraform com as permissões necessárias para criar/excluir projetos, etc. Comece com o mínimo e, conforme aparecerem erros, vá adicionando os papéis necessários sob demanda.

Um dos meus colegas escreveu um ótimo artigo sobre "Refactoring Terraform The Right Way", em linha com as recomendações do time da Gruntwork.io, criadores do Terragrunt. Resumindo: separe seus resources, services e ambientes live em três repositórios distintos e gerencie as permissões de grupo no controle de versão de acordo com isso.

Monitoramento e alertas precisam estar na linha de frente do seu planejamento e, felizmente, há vários recursos nativos do Google Cloud Platform que facilitam essa tarefa. O scan de benchmarks CIS no Cloud Security Command Center (CSCC), abaixo, detecta monitoramentos ausentes e dá instruções passo a passo para configurar corretamente cada projeto. Veja mais sobre o CSCC adiante.

Para facilitar, aqui está um Gist com as configurações de monitoramento recomendadas.

Omiti as VMs dos bastion hosts no diagrama acima por simplicidade, mas a boa prática para acesso seguro é usá-las. Sugiro reservar uma faixa de sub-rede por projeto para a VM do bastion host, eliminar todos os IPs externos e configurar clusters privados. Crie um managed instance group de uma instância para que o GCP suba uma nova caso ela falhe. Você pode se conectar ao bastion via VPN ou, na abordagem moderna e mais segura, usando o Cloud Identity Aware Proxy (IAP). Para reforçar ainda mais, restrinja as chaves SSH dos usuários no bastion.

Fonte: Google

Existem vários artigos sobre boas práticas de Kubernetes, mas este, escrito por engenheiros do Google, sobre "Completely Private GKE Clusters With No Internet Connectivity", é uma boa referência e reforça a estrutura básica proposta acima.

Você precisa planejar e desenhar sua infraestrutura para atender às políticas definidas pelo time de segurança da sua organização e, com frequência, isso envolve diferentes níveis de criptografia. Os recursos do GCP são criptografados em repouso por padrão, mas você deve identificar suas necessidades de chaves de criptografia (gerenciadas pelo Google, autogerenciadas, BYOK) tanto em repouso quanto em trânsito.

Você também pode querer isolar o acesso a dados dentro da organização, até no nível de pessoas ou aplicações. Isso é possível com o VPC Service Controls, conforme ilustrado abaixo.

Se você está enviando logs ou dados para monitoramento, como ilustrado no exemplo de hierarquia de recursos, vale configurar seus log sinks para usar as APIs do Cloud Data Loss Prevention (Cloud DLP) e remover quase 100 tipos de dados PII antes do armazenamento.

Uma joia escondida do GCP é o Cloud Security Command Center. Esse produto oferece uma visão unificada para gestão de ativos, detecção de ameaças e anomalias, WAF e varredura de vulnerabilidades. Uma das funcionalidades mais legais, na minha opinião, é o scan — você pode configurar quais projetos serão escaneados, mas não pode controlar quando isso acontece (1 a 2 vezes por dia). Ele aponta as violações de benchmarks CIS e NIST de cada projeto e recurso, com remediação passo a passo.

Observação: o novo modelo de preços dividirá o CSCC em duas camadas (free e premium).

Cloud Security Command Center — fonte: wideops.com

• Um ótimo recurso/checklist é o CIS Benchmarks for Google Cloud — há versões específicas para Kubernetes e outros sistemas, todas gratuitas

Existem outras ótimas ferramentas de terceiros, como o Forseti Security e o Prisma Cloud da Palo Alto Networks, para escanear e otimizar suas configurações e deploys de código (antigamente Twistlock e Redlock).

Nem precisa dizer, mas você precisa ter um plano automatizado de backup e recuperação para todos os seus dados, sejam em buckets ou em bancos de dados. Pratique o processo de backup e restore pelo menos uma vez por ano — de preferência com frequência ainda maior.

Para continuidade de negócios e tranquilidade, é altamente recomendado definir sua infraestrutura como código (IaC) usando Terraform. Se o time for disciplinado em manter o estado da infraestrutura como código, fica fácil gerar relatórios de auditoria para compliance e se recuperar de falhas catastróficas.

Mal arranhei a superfície dos pontos-chave de uma transformação de nuvem corporativa, e tudo isso pode parecer assustador, mas o melhor a fazer é simplesmente começar. Posso ser suspeito, mas a segunda melhor coisa para aumentar suas chances de sucesso é se unir a profissionais que já passaram por isso muitas vezes.

A DoiT International já ajudou milhares de empresas em suas jornadas na nuvem, com revisões de arquitetura, suporte especializado e ferramentas customizadas de orçamento e relatórios na nuvem — tudo sem custo adicional para nossos clientes (somos um cloud reseller partner). Nosso objetivo é capacitar e empoderar seu time para gerenciar com sucesso sua infraestrutura de nuvem, mas, quando precisar, estamos sempre por perto.

Quer mais conteúdos do Mike? Confira nosso blog no Medium ou siga o Mike no Twitter.