Acessando recursos da AWS com segurança no Github Actions
Tags: aws, cloud, devops, braziliandevs
Published: 2023-01-26 23:27:50

# 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é](https://twitter.com/Benoit_Boure), em [Securely Access Your AWS Resources From Github Actions](https://benoitboure.com/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](https://docs.github.com/en/actions/security-guides/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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1640544136378/7f72xtMx3.png)

## 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](https://console.aws.amazon.com/iamv2/home?#/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_

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1640547423605/DPAcFf-vK.png)

> 💡 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`

{% embed https://twitter.com/Benoit_Boure/status/1481537078869565440 %}

---

## 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](https://console.aws.amazon.com/iamv2/home?#/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_

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1640267179031/LAbzvscMB.png)

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](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege).

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:

```yaml
"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](https://git-scm.com/book/en/v2/Git-Internals-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:

```yaml
{
  "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.

```yaml
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](https://github.com/aws-actions/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:

```yaml
- 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](https://github.com/aws-actions/configure-aws-credentials#sample-iam-role-cloudformation-template) que você pode usar para automatizar as etapas de configuração da AWS.

Usando isso, eu fui adiante; Eu crirei um [modelo](http://githubactions-oidc-cfn.s3.amazonaws.com/template.yml) e também um link de implantação direto.

Você pode usá-lo [clicando aqui](https://us-east-1.console.aws.amazon.com/cloudformation/home?region=eu-west-1#/stacks/quickcreate?templateURL=http://githubactions-oidc-cfn.s3.amazonaws.com/template.yml&stackName=GithubActionsOIDC) 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](https://hashnode.com/@bboure), no Twitter em [@Benoit_Boure](https://twitter.com/Benoit_Boure), e não se esqueça de [assinar minha newsletter](https://benoitboure.com/newsletter).