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 clicarGet 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 2022Benoît Bouré ⚡️ @Benoit_BoureI 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-assumeem 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.
Top comments (0)