Aprenda a gerar credenciais de curta duração para acessar sua conta AWS a partir dos fluxos de trabalho no Github Actions

Créditos

• Escrito originalmente por Benoît Bouré, em Securely Access Your AWS Resources From Github Actions.

A segurança é um tópico muito importante para todos os engenheiros trabalhando na nuvem. Garantir que sua infraestrutura e dados sejam mantidos fora do alcance de pessoas maliciosas é uma das coisas mais sérias para fazer corretamente. Na AWS, estamos acostumados a lidar com funções e permissões de IAM que tornam nossos recursos acessíveis aos usuários ou a outros recursos. No entanto, às vezes você precisa conceder acesso de fora da sua organização.

Um exemplo é quando você deseja implantar sua infraestrutura a partir de um pipeline de CI/CD, como os Github Actions. Como você permite que seu fluxo de trabalho obtenha acesso à sua conta da AWS?

Uma abordagem é criar um usuário dedicado do IAM, armazenar suas credenciais no Github Encrypted Secrets, e permitir que o fluxo de trabalho os use. Fácil, chega! Segredos são criptografados pelo Github, por isso é seguro, certo?

Na verdade não... O problema é que esses tipos de credenciais tem um tempo de duração muito longo. Isso significa que, se alguém acessar os valores por qualquer motivo (por exemplo: um vazamento nos logs da CI/CD, alguém que tenha acesso ao GitHub Runner, etc). Eles poderão acessar todos os seus recursos (pelo menos aqueles que as credenciais podem controlar). Claro, você pode fazer a rotação das credenciais de tempos em tempos, mas você teria que fazer isso manualmente. Provavelmente não é algo que você quer gastar e, vamos ser sinceros, você provavelmente não vai querer!

Felizmente, existe uma solução melhor. Se você estiver usando os Github Actions, você pode permitir que o Github obtenha credenciais temporárias e de curta duração para ser usado nas suas ações. Depois disso, as credenciais expirarão e ninguém poderá usá-las novamente.

Neste post, eu o guiarei pelas etapas para configurar isso. Não se preocupe, é realmente mais fácil do que você pensa!

Aqui está um esquema que representa o que vamos realizar

Configurando sua conta AWS

💡 TL; DR; Criei um link de criação rápida do CloudFormation que você pode usar para automatizar as etapas a seguir. Veja na parte inferior deste artigo. Se você quiser saber como funciona e o que o CloudFormation fará, continue lendo esta seção.

Crie um provedor de identidade de conexão OpenID

O primeiro passo é criar um provedor de identidade OpenID Connect (OIDC) em sua conta AWS. Isso permitirá que Github se identifique.

• Vá até o IAM Console -> Identity providers
• Clique Add new provider
• Selecione OpenID Connect
• Usar a seguinte URL fornecida pelo GitHub: https://token.actions.githubusercontent.com (Não se esqueça de clicar Get Thumbprint)
• Audience: sts.amazonaws.com
• Adicione tags, se desejar, e clique em Add Provider

💡 Você precisará fazer essa etapa apenas uma vez por conta da AWS.

Atualização: 13 de janeiro de 2022

Em 12 de janeiro, o Github Actions mudou sua cadeia de certificados. A nova impressão digital é 6938fd4d98bab03faadb97b34396831e3780aea1

Benoît Bouré ⚡️

@benoit_boure

Apparently, Github Actions integration broke yesterday after they changed their certs.

You'll need to update the fingerprint to

6938fd4d98bab03faadb97b34396831e3780aea1 twitter.com/Benoit_Boure/s…

08:02 AM - 13 Jan 2022

Benoît Bouré ⚡️ @Benoit_Boure

I just published a new article! Learn how to securely access your AWS resources from Github Actions workflows. https://t.co/wZUUVwQ21U

Crie uma IAM Role

Agora você precisa criar uma IAM Role que o Github possa assumir para acessar os recursos necessários para controlar.

• Volte para o IAM Console e selecione Roles
• Crie um novo IAM Role
• Escolha Web Identity, selecione o provedor de identidade que você criou na etapa anterior e sua Audience.
• Clique Next: Permissions

Agora você precisa atribuir permissões apropriadas (IAM Policies) para essa IAM Role. Estas são as permissões que o Github precisa para fazer o que for preciso. Isso variará com base no seu caso de uso, então deixarei isso com você. Lembre-se de que você deve manter o princípio de menor privilégios.

Quando isso for feito, dê um nome à sua IAM Role e clique em Create Role.

Agora há um passo adicional a ser feito. Você precisa editar a política de confiança da IAM Role (trust policy) para reduzir o escopo de acesso para apenas o seu repositório. Certifique-se de não pular esta parte, é muito importante. Sem isso, qualquer repositório no GitHub poderá assumir sua função e acessar seus recursos.

Até o momento, não há uma maneira de fazer isso no momento da criação, infelizmente.

• Volte para a lista de IAM Roles e selecione a função criada.
• Clique em Trust Relationship
• E finalmente, clique em Edit Trust Relationship

Dentro da chave Condition, adicione a seguinte declaração:

"StringLike": {
  "token.actions.githubusercontent.com:sub": "repo:[nome-da-org]/[nome-do-repo]:*"
}

Substitua os nomes da organização e do repo para corresponder aos seus e clique em Update Trust Policy.

Nota: Você pode levar isso ainda mais longe e reduzir o escopo usando Git References, usando o nome de uma branch ou tag. Por exemplo: repo:[nome-da-org]/[nome-do-repo]:ref:refs/heads/master

O resultado final será assim:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::1234567890:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:[nome-da-org]/[nome-do-repo]:*"
        }
      }
    }
  ]
}

Isso conclui as configurações necessárias na sua conta da AWS. Anote o valor do ARN, você precisará dele mais tarde.

💡 Você pode criar IAM Roles diferentes por conta e usar uma diferente para cada caso de uso. Por exemplo, um por aplicativo, por uso (configurações, deploy, testes de integração, etc). Você pode brincar com isso para reduzir ainda mais o escopo de cada sessão.

Configurando seu Github Actions

Seu Github Actions requer permissões adicionais para poder usar o OIDC. Adicione o seguinte na parte superior do arquivo YML da sua ação. Você também pode adicioná-lo por job, para reduzir o escopo, se necessário.

permissions:
  id-token: write # obrigatório para usar autenticação OIDC
  contents: read # obrigatório para clonar o código do repositório

Agora você pode usar o GitHub Action configure-aws-credentials no seu job, para assumir a IAM Role criada. Adicione esta etapa para gerar credenciais antes de fazer qualquer chamada para a AWS:

- name: configure aws credentials
  uses: aws-actions/configure-aws-credentials@v1
  with:
    role-to-assume: arn:aws:iam::1234567890:role/your-role-arn
    role-duration-seconds: 900 # o TTL da sessão, em segundos.
    aws-region: us-east-1 # sua região
# 👇 Agora você pode executar comandos que usarão a suas credenciais
- name: Serverless deploy
  run: sls deploy --stage dev

A etapa configure aws credentials usará a integração OIDC para assumir a função especificada, gerar credenciais de curta duração e disponibilizar a sessão para os comandos do trabalho atual.

💡 Se você quiser levar a segurança ainda mais longe, você pode definir o ARN da sua IAM Role usado em role-to-assume em um segredo do Github.

Automatizar

O pessoal do configure-aws-credentials compartilhou um modelo de CloudFormation que você pode usar para automatizar as etapas de configuração da AWS.

Usando isso, eu fui adiante; Eu crirei um modelo e também um link de implantação direto.

Você pode usá-lo clicando aqui para fazer o deploy em sua conta.

Preencha os parâmetros:

• GitHubOrg: nome da sua organização ou nome de usuário do Github
• RepositoryName: o repositório que precisa de acesso à sua conta AWS
• OIDCProviderArn: ARN do seu provedor OIDC existente, se você já tiver um. Caso contrário, deixe-o em branco e um será criado para você. (Lembre-se de que você só precisa de um por conta).

Nota: A IAM Role criada não terá nenhuma IAM Policy anexada a ela. Você ainda precisará anexar as permissões que o seu trabalho no GitHub Actions precisa acessar.

Conclusão

Como você pode ver, proteger sua conta não precisa ser difícil. A parte que pode exigir um pouco mais de esforço é definir as IAM Policies corretas se você quiser seguir o princípio de menos privilégios (e que você deve!).

Para mais conteúdo como este, siga-me aqui no Hashnode em bboure, no Twitter em @Benoit_Boure, e não se esqueça de assinar minha newsletter.