AWS de Dev pra Dev: Credentials e acesso programtico - parte 2

Essa a parte 2 dessa srie de posts sobre credenciais e acesso programtico. Na parte 1 ns discutimos sobre IAM Users, credenciais e como utilizar essas a CLI para invocar APIs do AWS.

Nesse post, vamos explorar sobre IAM Roles.

Glossrio

• IAM: IAM (Identity and Access Management) um servio do AWS que permite que os usurios gerenciem as permisses de acesso aos seus recursos AWS. Com o IAM, os usurios podem criar e gerenciar usurios e grupos, e definir polticas de acesso para esses usurios e grupos.
• IAM User: IAM User um usurio individual criado e gerenciado no AWS IAM. Um IAM user pode ser associado a uma conta de usurio, ou seja, uma conta de usurio pode ter vrios IAM users.
• IAM Group: IAM Group um conjunto de usurios IAM que compartilham as mesmas permisses de acesso. Ao adicionar um usurio a um grupo, esse usurio herda as permisses do grupo.
• SDK: SDK (Software Development Kit) uma coleo de ferramentas de desenvolvimento de software fornecida por fornecedores de servios e plataformas, como o AWS, para permitir que os desenvolvedores interajam com os servios de uma forma programtica. Existem SDKs disponveis para vrias linguagens de programao, como Java, Python e C#.
• IaC: IaC (Infrastructure as Code) uma tcnica para gerenciar a infraestrutura de TI de uma organizao como cdigo, usando ferramentas de automao como o AWS CloudFormation ou Terraform. Isso permite que os usurios provisionem, gerenciem e documentem sua infraestrutura de forma automatizada e consistente, e facilita a implantao de mudanas e a reproduo de configuraes.
• ARN: AWS ARN (Amazon Resource Name) uma string nica que identifica de forma segura e consistente recursos dentro do Amazon Web Services (AWS). Ele composto por vrios elementos, como o servio, a regio, a conta e o nome do recurso, e usado para permitir acesso a recursos especficos na sua conta AWS. Por exemplo, um ARN de funo AWS Lambda pode ser usado para permitir que outro recurso da AWS, como uma tabela do Amazon DynamoDB, acesse a funo.

1. O que um IAM Role?

O IAM Role (vou chamar apenas de Role) um tipo de identidade fornecida pelo servio AWS IAM. A principal diferena entre o Role e o User que o primeiro pode ser utilizado por qualquer usurio, aplicao ou recurso que precise utiliz-lo, j o segundo associado a um usurio ou aplicao.

2. Quando eu devo usar um IAM Role?

Roles so bem teis em situaes especficas:

• Dar acesso a recursos rodando DENTRO do AWS para invocar servios do AWS.
• Dar acesso a recursos rodando FORA do AWS para invocar servios do AWS.
• Garantir acesso a servios do AWS para executar aes em sua conta.
• Dar acesso a outra conta do AWS para executar aes em sua conta.

3. Como eu crio um Role?

Primeiro, voc tem que criar um Role no IAM.
Normalmente, como uma pessoa dev, voc vai utilizar a SDK ou utilizar IaC para criar o seu Role, por exemplo, utilizando o AWS CloudFormation:

Resources:  LambdaRole:    Type: "AWS::IAM::Role"    Properties:      RoleName: LambdaRole      Description: "Role used to grant permissions to an AWS Lambda function"      AssumeRolePolicyDocument:        Version: "2012-10-17"        Statement:          - Effect: Allow            Principal:              Service: "lambda.amazonaws.com"            Action: "sts:AssumeRole"          - Effect: Allow            Principal:               AWS:                 Ref: AWS::AccountId            Action: "sts:AssumeRole"      Policies:        - PolicyName: WriteToS3Policy          PolicyDocument:            Version: "2012-10-17"            Statement:              - Effect: Allow                Action:                   - "s3:PutObject"                  - "s3:ListAllMyBuckets"                Resource: "arn:aws:s3:::*"

O Role acima tem duas partes principais:

• AssumeRolePolicyDocument: Esse bloco define quais principals do AWS podem assumir esse role.
• Policies: Nesse bloco ns definimos quais aes o Role tem permisso para executar. No nosso caso, o role tem permisso para executar as aes "s3:putObject" e "s3:ListBucket" em qualquer bucket do AWS.

Quer fazer um teste? Copie o cdigo acima para um arquivo .yaml e execute o seguinte comando:

Nota: O comando abaixo requer que sua CLI esteja configurada. D uma olhada na parte 1 sobre como usar a CLI.

aws cloudformation create-stack --stack-name example --template-body file://<path para o seu aquivo.yaml> --capabilities CAPABILITY_NAMED_IAM

Voc pode verificar que o recurso foi criado utilizando o seguinte comando do CloudFormation

 aws cloudformation list-stack-resources --stack-name example

Voc deve conseguir ver algo com o "ResourceStatus": "CREATE_COMPLETE".

E finalmente, voc pode conferir o resultado da execuo do template acima usando a CLI pra pegar detalhes sobre o Role:

aws iam get-role --role-name LambdaRole

Observe como o trecho Principal: AWS: Ref: AWS::AccountId foi substitudo por sua conta. Isso significa que qualquer usurio daquela conta pode assumir aquele Role.

4. Como eu uso um Role?

Com o Role criado agora ns podemos utiliz-lo. As formas mais comuns so:

• Assumir um Role: Voc pode usar a funo AssumeRole da AWS STS (Security Token Service) para assumir um Role em outra conta de usurio ou na sua prpria conta.
• Atribuir um Role a uma instncia: voc pode atribuir um papel a uma instncia do EC2 (Elastic Compute Cloud). Isso permite que a instncia acesse recursos usando as permisses do Role.
• Atribuir um Role a um servio: alguns servios do AWS, como o Lambda, suportam a atribuio de um Role ao servio. Isso permite que o servio acesse recursos usando as permisses do Role.
• Usar um Role com o SDK: Voc pode usar um papel com o SDK do AWS para acessar recursos usando as permisses do Role. Isso geralmente envolve a configurao de credenciais de acesso temporrias usando a funo AssumeRole.

5. Assumindo um Role com a CLI

Vamos fazer um experimento, usando um usurio que no tenha permisses para o s3, execute o seguinte comando:

aws s3 ls

Observe como a sada do comando foi o seguinte erro:

An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied

Agora, vamos assumir o Role usando um User ou Role que voc tenha criado que possua permisso pra ao AssumeRole. Qualquer User ou Role funciona, desde que tenha a seguinte permisso:

AssumeRolePolicyDocument:        Version: "2012-10-17"        Condition:          - Effect: Allow            Principal:              AWS:                Ref: AWS::AccountId            Action: "sts:AssumeRole"            Resource:              "arn:aws:iam::ACCOUNT_ID:role/LambdaRole"

Calma, no se assuste. Vamos ver o que essa permisso faz. Ela muito similar s permisses que demos quando criamos o LambdaRole. Ns estamos dando permisso a qualquer usurio da nossa conta (Ref: AWS::AccountId) ao sts:AssumeRole, ao recurso representado pelo AWS ARN "arn:aws:iam::ACCOUNT_ID:role/LambdaRole".

Lembre-se que a policy precisa ser associado a um usurio ou outro Role (sim, Roles podem assumir Roles). Fica o dever de casa de voc criar esse usurio (a parte 1 pode te ajudar com isso).

Antes de continuar, execute o seguinte comando e anote a identidade que voc est utilizando no momento.

aws sts get-caller-identity

Agora que voc tem um usurio com permisso de AssumeRole vamos usar esse usurio para executar o seguinte comando:

aws sts assume-role --role-arn arn:aws:iam::<YOUR_ACCOUNT_ID>:role/LambdaRole --role-session-name my-session

Voc vai receber um retorno com as seguintes variveis:

AccessKeyIdSecretAccessKeySessionToken

Copie esses valores e execute o comando abaixo:

export AWS_ACCESS_KEY_ID=<AccessKeyId> && export AWS_SECRET_ACCESS_KEY=<SecretAccessKey> && export AWS_SESSION_TOKEN=<SessionToken>

Com essas variveis setadas, vamos verificar que ns agora estamos usando a identidade do nosso role. Execute novamente o comando:

aws sts get-caller-identity

Observe como o seu ARN mudou. Ele agora deve ser algo do tipo:

arn:aws:sts::<YOUR_ACCOUNT_ID>:assumed-role/LambdaRole/my-session

Agora que ns estamos usando a identidade do nosso Lambda Role ns podemos finalmente re-executar nosso comando:

aws s3 ls

E o resultado, deve ser uma lista com todos os buckets que voc tem na sua conta. Se no listou nada, v l na sua conta e crie uns buckets s pra brincar.

6. Usando IAM Roles no acesso entre contas (cross-account)

Outra coisa legal que podemos fazer com Roles dar acesso a outras contas. O princpio o mesmo, no seu Role voc precisa declarar a TrustedPolicy apontando as identidades na outra conta que podem assumir o seu Role.
Na sua outra conta, lembre-se que voc precisa dar permisso ao assumeRole.

Um exemplo usando CloudFormation. Na sua conta "origem" voc pode declarar:

Resources:  TargetRole:    Type: "AWS::IAM::Role"    Properties:      AssumeRolePolicyDocument:        Version: "2012-10-17"        Statement:          - Effect: Allow            Principal:              AWS:                - "arn:aws:iam::DESTINO_ACCOUNT_ID:root"            Action: "sts:AssumeRole"      Policies:        - <QUALQUER POLICY QUE VOC DESEJAR, POR EXEMPLO, A NOSSA POLICY DE ACESSO AO S3>

E finalmente, na outra conta, voc pode fazer:

Resources:  SourceRole:    Type: "AWS::IAM::Role"    Properties:      AssumeRolePolicyDocument:        Version: "2012-10-17"        Condition:          - Effect: Allow            Principal:              AWS:                - "arn:aws:iam::DESTINO_ACCOUNT_ID:root"            Action: "sts:AssumeRole"            Resource: "arn:aws:iam::ORIGEM_ACCOUNT_ID:role/TARGET_ROLE_NAME"

Preste ateno nessa ltima parte. Note o trecho:

Principal:    AWS:        - "arn:aws:iam::DESTINO_ACCOUNT_ID:root"

Veja como ali usamos a conta "Destino", ou seja, a conta que vai assumir o Role. J nesse outro trecho:

Resource: "arn:aws:iam::ORIGEM_ACCOUNT_ID:role/TARGET_ROLE_NAME"

Ns usamos a conta "origem", ou seja, ns estamos dizendo que a conta "Destino" pode assumir o role na conta "Origem".

Importante, lembre-se que isso s funciona se na conta "origem" ns demos permisso para a conta "destino" tambm. Um pouco confuso eu sei. Eu gosto de pensar que um aperto de mos, como o estabelecimento de uma conexo. A conta origem precisa aceitar a conta destino, e a conta destino precisa ter permisso para executar a ao na conta origem. Sem a permisso nos dois lados, o nosso "aperto de mos" no funciona.

Concluso

Existem muitos detalhes sobre o uso de Roles. Eu passei longe de cobrir todos eles. Os aspectos mais importantes e que eu quero que fiquem com voc so:

• Roles so bem mais flexveis do que Users e na MINHA experincia, eu s trabalho com Roles.
• Existem diversos casos de uso pra Roles, os mais comuns so dar permisses a servios do AWS, acesso a outras contas e acesso a usurios.
• Quando voc assume o Role voc tem as mesmas permisses que o Role tem.
• Finalmente, pra assumir um Role, o Role origem precisa ter uma TrustedPolicy que d permisso a identidade destino e a identidade destino precisa ter permisso de executar a ao assumeRole.

Eu sei que foi muita informao, mas eu espero que esse post d uma facilitada na sua jornada de entender o AWS. Se ficou alguma dvida, me pergunta a nos comentrios.

Muito obrigado pela leitura
Gostou? Me segue aqui no dev.to e no (Twitter)[https://twitter.com/hugaomarques]

Quer aprender mais?

D uma assistida nessa talk da fantstica Becky Weiss:

"Happy Coding!"