O blog da AWS

Estenda as AWS IAM Roles para workloads fora da AWS com o IAM Roles Anywhere

 Por Faraz Angabini, especialista sênior em segurança na AWS
 

O AWS Identity and Access Management (IAM) agora tornou mais fácil o uso de IAM Roles para seus workloads executados fora da AWS, com o anúncio do IAM Roles Anywhere. Essa funcionalidade estende os recursos das IAM Roles para workloads fora da AWS. Você pode usar o IAM Roles Anywhere afim de fornecer uma maneira segura para servidores, containers ou aplicações on-premises obterem credenciais temporárias da AWS, e com isso eliminar a necessidade de criar e gerenciar credenciais de longo prazo na AWS.

Nesta publicação, discutirei brevemente como o IAM Roles Anywhere funciona, mencionarei alguns dos casos de uso comuns do IAM Roles Anywhere e, por fim, darei um exemplo de cenário para demonstrar como a implementação funciona.

 

Panorama Geral

Para permitir que suas aplicações acessem serviços e recursos da AWS, você precisa fornecer à aplicação credenciais válidas da AWS para fazer solicitações de API da AWS. Para workloads em execução na AWS, isso é feito associando uma IAM Role ao Amazon Elastic Compute Cloud (Amazon EC2)Amazon Elastic Container Service (Amazon ECS)Amazon Elastic Kubernetes Service (Amazon EKS) ou recursos do AWS Lambda, dependendo da plataforma de computação que hospeda sua aplicação. Isso é seguro e conveniente, porque você não precisa distribuir e gerenciar credenciais da AWS para aplicações executadas na AWS. Em vez disso, a IAM Role fornece credenciais temporárias que as aplicações podem usar quando fazem chamadas de API da AWS.

O IAM Roles Anywhere permite que você use IAM Roles em suas aplicações fora da AWS, afim de acessar APIs da AWS com segurança, da mesma forma que você usa IAM Roles para workloads dentro da AWS. Com o IAM Roles Anywhere, você pode fornecer credenciais de curto prazo para seus servidores on-premises, containers ou outras plataformas de computação. Ao usar o IAM Roles Anywhere para fornecer credenciais de curto prazo, você pode eliminar a necessidade de chaves de acesso e segredos de longo prazo da AWS, o que pode ajudar a melhorar a segurança e remover a sobrecarga operacional de gerenciar e rotacionar as credenciais de longo prazo. Você também pode usar o IAM Roles Anywhere para fornecer uma experiência consistente para o gerenciamento de credenciais em workloads híbridos.

Neste post, presumo que você tenha um conhecimento básico do IAM, então não vou entrar em detalhes sobre as IAM Roles. Para obter mais informações sobre as IAM Roles, consulte a documentação do IAM.

 

Como o IAM Roles Anywhere funciona?

O IAM Roles Anywhere depende da infraestrutura de chave pública (PKI) para estabelecer a confiança entre sua conta da AWS e a autoridade de certificação (CA) que emite certificados para seus workloads on-premises. Seus workloads fora da AWS usam o IAM Roles Anywhere para trocar certificados X.509 por credenciais temporárias da AWS. Os certificados são emitidos por uma CA que você registra como trust anchor (root of trust) no IAM Roles Anywhere. A CA pode fazer parte do seu sistema de PKI existente ou ser uma CA criada por você com o AWS Certificate Manager Private Certificate Authority (ACM PCA).

Sua aplicação faz uma solicitação de autenticação para o IAM Roles Anywhere, enviando com ela sua chave pública (codificada em um certificado) e uma assinatura assinada pela chave privada correspondente. Sua aplicação também especifica a Role a ser assumida na solicitação. Quando o IAM Roles Anywhere recebe a solicitação, ele primeiro valida a assinatura com a chave pública e, depois, valida se o certificado foi emitido por um trust anchor previamente configurado na conta. Para obter mais detalhes, consulte a documentação de validação de assinatura.

Depois que ambas as validações forem bem-sucedidas, sua aplicação será autenticada e o IAM Roles Anywhere criará uma nova Role Session para a Role especificada na solicitação, chamando o AWS Security Token Service (AWS STS). As permissões efetivas para essa sessão da Role são a interseção das identity-based policies da Role de destino e das session policies, se especificadas, no perfil que você cria no IAM Roles Anywhere. Como qualquer outra sessão do IAM Role, ela também está sujeita a outros tipos de política que você possa ter em vigor, como permission boundaries e service control policies (SCPs).

Normalmente, existem três tarefas principais, executadas por diferentes personas, envolvidas na configuração e no uso do IAM Roles Anywhere:

  • Configuração inicial do IAM Roles Anywhere: essa tarefa envolve a criação de uma trust anchor, a configuração da Trust Policy da Role que o IAM Roles Anywhere assumirá e a definição do perfil da Role. Essas atividades são realizadas pelo administrador da conta da AWS e podem ser limitadas pelas políticas do IAM.
  • Provisionamento de certificados para workloads fora da AWS: essa tarefa envolve garantir que o certificado X.509, assinado pela CA, esteja instalado e disponível no servidor, container ou aplicação fora da AWS que precisa ser autenticado. Isso é realizado em seu ambiente on-premises por um administrador de infraestrutura ou agente de provisionamento, normalmente usando ferramentas já existentes de gerenciamento de configuração e automação.
  • Como usar o IAM Roles Anywhere: essa tarefa envolve a configuração da cadeia de provedores de credenciais para usar a credential helper tool do IAM Roles Anywhere para trocar o certificado por credenciais de sessão. Isso geralmente é realizado pelo desenvolvedor da aplicação que interage com as APIs da AWS.

Vou entrar nos detalhes de cada tarefa quando eu percorrer o cenário de exemplo mais adiante neste post.

 

Casos de uso comuns para o IAM Roles Anywhere

Você pode usar o IAM Roles Anywhere para qualquer workload em execução no seu datacenter ou em outros provedores de nuvem que exijam credenciais para acessar as APIs da AWS. Aqui estão alguns dos casos de uso que achamos que serão interessantes para os clientes com base nas conversas e nos padrões que vimos:

 

Exemplo de cenário e explicação passo a passo

Para demonstrar como o IAM Roles Anywhere funciona na prática, vamos percorrer um cenário simples em que você deseja chamar APIs do S3 para fazer upload de alguns dados de um servidor em seu datacenter.

Pré-requisitos

Antes de configurar o IAM Roles Anywhere, você precisa ter os seguintes requisitos:

  • Pacote de certificados da sua própria CA, ou uma CA ACM PCA ativa na mesma região da AWS que o IAM Roles Anywhere
  • Um certificado de entidade final e uma chave privada associada disponível no servidor on-premises
  • Permissões de administrador para IAM Roles e IAM Roles Anywhere

Configuração

Aqui, demonstro como executar o processo de configuração usando a console do IAM Roles Anywhere. Como alternativa, você pode usar a API da AWS ou a interface de linha de comando (CLI) para executar essas ações. Há três atividades principais aqui:

  • Criar um trust anchor
  • Criar e configurar uma Role que confie no IAM Roles Anywhere
  • Criar um perfil

Para criar uma trust anchor

  1. Navegue até a console do IAM Roles Anywhere.
  2. Em Trust anchors, escolha Create a trust anchor
  3. Na página Create a trust anchor, insira um nome para sua trust anchor e selecione a CA privada existente do AWS Certificate Manager na lista. Como alternativa, se você quiser usar sua própria CA externa, escolha External certificate bundle (Pacote de certificados externos) e forneça o pacote de certificados.
Figure 1: Create a trust anchor in IAM Roles AnywhereFigura 1: criar uma trust anchor no IAM Roles Anywhere

 

Para criar e configurar uma Role que confia no IAM Roles Anywhere

  1. Usando a AWS Command Line Interface (AWS CLI), você criará uma IAM Role com as permissões apropriadas que você deseja que seu servidor on-premises assuma após a autenticação no IAM Roles Anywhere. Salve a seguinte Trust Policy como rolesanywhere-trust-policy.json em seu computador.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "rolesanywhere.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:SetSourceIdentity",
                "sts:TagSession"
            ]
        }
    ]
}

 

2. Salve a seguinte identity-based policy como onpremsrv-permissions-policy.json. Isso concede à Role permissões para gravar objetos no bucket do S3 especificado.

 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<DOC-EXAMPLE-BUCKET>/*"
        }
    ]
}

 

3. Execute os dois comandos da AWS CLI a seguir para criar a Role e anexar a política de permissões.

 

aws iam create-role \
--role-name ExampleS3WriteRole \
--assume-role-policy-document file://<path>/rolesanywhere-trust-policy.json



aws iam put-role-policy \
--role-name ExampleS3WriteRole \
--policy-name onpremsrv-inline-policy \
--policy-document file://<path>/onpremsrv-permissions-policy.json

Outra opção é usar instruções de Condition com base nos atributos extraídos do certificado X.509 para restringir ainda mais a Trust Policy afim de controlar os recursos on-premises que podem obter credenciais do IAM Roles Anywhere. O IAM Roles Anywhere define o valor SourceIdentity para o CN do assunto (onpremsrv01 no meu exemplo). Ele também define tags de sessão individuais (PrincipalTag/) com os atributos derivados do certificado. Portanto, você pode usar as tags principais na cláusula Condition na Trust Policy como restrições adicionais de autorização.

Por exemplo, o Subject para o certificado que eu uso nesta publicação é o seguinte.

Subject: … O = Example Corp., OU = SecOps, CN = onpremsrv01

Portanto, posso adicionar declarações de Condition como as exibidas a seguir na Trust Policy (rolesanywhere-trust-policy.json):

...
    "Condition": {
        "StringEquals": {
            "aws:PrincipalTag/x509Subject/CN": "onpremsrv01",
            "aws:PrincipalTag/x509Subject/OU": "SecOps"
        }
    }
...

Para saber mais, consulte a documentação da trust policy do IAM Roles Anywhere.

 

Para criar um perfil

  1. Navegue até a console do Roles Anywhere.
  2. Em Profiles (Perfis), escolha Create a profile (Criar um perfil).
  3. Na página Create a profile (Criar um perfil), insira um nome para o perfil.
  4. Em Roles , selecione um perfil que você criou na etapa anterior (ExampleS3WriteRole).
  5. Opcionalmente, você pode usar session policies para definir ainda mais o escopo das sessões entregues pelo IAM Roles Anywhere. Isso é particularmente útil quando você configura o perfil com várias Roles e deseja restringir as permissões em todas elas. Você pode adicionar as session policies desejadas como Managed Policies ou Inline Policies. Aqui, para fins de demonstração, adiciono uma Inline Policy para permitir apenas solicitações provenientes do meu endereço IP especificado.
Figure 2: Create a profile in IAM Roles AnywhereFigura 2: criar um perfil no IAM Roles Anywhere

 

Nesse momento, a configuração do IAM Roles Anywhere está concluída e você pode começar a usá-la.

 

Uso do IAM Roles Anywhere

O IAM Roles Anywhere fornece uma ferramenta auxiliar de credenciais que pode ser usada com a funcionalidade de credenciais de processo compatível com todos os SDKs atuais da AWS. Isso simplifica o processo de assinatura das aplicações. Consulte a documentação do IAM Roles Anywhere para saber como obter a credential helper tool.

Para testar a funcionalidade primeiro, execute a credential helper tool (aws_signing_helper) manualmente no servidor on-premises da seguinte maneira.

./aws_signing_helper credential-process \
    --certificate /path/to/certificate.pem \
    --private-key /path/to/private-key.pem \
    --trust-anchor-arn <TA_ARN> \
    --profile-arn <PROFILE_ARN> \
    --role-arn <ExampleS3WriteRole_ARN>
Figure 3: Running the credential helper tool manuallyFigura 3: execução manual da ferramenta auxiliar de credenciais

 

Você deve receber as credenciais de sessão do IAM Roles Anywhere, conforme o exemplo da figura 3. Depois de confirmar que a configuração funciona, atualize ou crie o arquivo ~/.aws/config e adicione o signing helper como um credential_process. Isso habilitará o acesso autônomo para o servidor on-premises. Para saber mais sobre o arquivo de configuração da AWS CLI, consulte Configuration and credential file settings (Configurações do arquivo de configuração e credencial).

 

# ~/.aws/config content
[default]
 credential_process = ./aws_signing_helper credential-process
    --certificate /path/to/certificate.pem
    --private-key /path/to/private-key.pem
    --trust-anchor-arn <TA_ARN>
    --profile-arn <PROFILE_ARN>
    --role-arn <ExampleS3WriteRole_ARN>

Para verificar se a configuração funciona conforme o esperado, execute o comando aws sts get-caller-identity da AWS CLI e confirme se a Role assumida é a que você configurou no IAM Roles Anywhere. Você também deve ver que o nome da sessão da Role contém o número de série do certificado que foi usado para autenticar (cc:c3:…:85:37, neste exemplo). Por fim, você deve ter permissões para copiar um arquivo para o bucket do S3, conforme mostrado na figura 4.

Figure 4: Verify the assumed roleFigura 4: verificar a Role assumida

 

Auditoria

Assim como ocorre com outros serviços da AWS, o AWS CloudTrail captura chamadas de API para o IAM Roles Anywhere. Vejamos as entradas de logs correspondentes do CloudTrail para as atividades que realizamos anteriormente.

A primeira entrada de logs na qual estou interessado é CreateSession, quando o servidor on-premises invoca o IAM Roles Anywhere por meio da credential helper tool e recebeu as credenciais da sessão como resposta.

{
    ...
	"eventSource": "rolesanywhere.amazonaws.com",
    "eventName": "CreateSession",
    ...
    "requestParameters": {
        "cert": "MIICiTCCAfICCQD6...mvw3rrszlaEXAMPLE",
        "profileArn": "arn:aws:rolesanywhere:us-west-2:111122223333:profile/PROFILE_ID",
        "roleArn": "arn:aws:iam::111122223333:role/ExampleS3WriteRole",
        ...
    },
    "responseElements": {
        "credentialSet": [{
            "assumedRoleUser": {
                "arn": "arn:aws:sts::111122223333:assumed-role/ExampleS3WriteRole/00ccc3a2432f8c5fec93f0fc574f118537",
            },
            "credentials": {
                "accessKeyId": "ASIAIOSFODNN7EXAMPLE",
                "expiration": "2022-07-06T00:46:43Z",
                "secretAccessKey": "HIDDEN_DUE_TO_SECURITY_REASONS",
                "sessionToken": "IQoJAQoDYXdzEJr..."
            },
            ...
            "sourceIdentity": "CN=onpremsrv01"
        }],
    },
    ...
}

Você pode ver que o parâmetro cert, juntamente com outros, é enviado para o IAM Roles Anywhere e que uma sessão da Role junto com credenciais temporárias é enviada de volta ao servidor.

A próxima entrada de logs que queremos ver é o da chamada s3:PutObject que fizemos do nosso servidor on-premises.

{
    ...
    "eventSource": "s3.amazonaws.com",
    "eventName": "PutObject",
    "userIdentity":{
        "type": "AssumedRole",
        "arn": "arn:aws:sts::111122223333:assumed-role/ExampleS3WriteRole/00ccc3a2432f8c5fec93f0fc574f118537",
        ...
        "sessionContext":
        {
            ...
            "sourceIdentity": "CN=onpremsrv01"
        },
    },
    ...
}

Além dos logs do CloudTrail, há várias métricas e eventos disponíveis para você usar para fins de monitoramento. Para saber mais, consulte Monitoring IAM Roles Anywhere (Monitoramento do IAM Roles Anywhere).

 

Notas adicionais

Você pode desabilitar a trust anchor no IAM Roles Anywhere para impedir imediatamente que novas sessões sejam emitidas para seus recursos fora da AWS. A revogação de certificados é suportada por meio do uso de listas de revogação de certificados (CRLs) importadas. Você pode fazer upload de uma CRL gerada por meio da CA, e os certificados usados para autenticação serão verificados quanto ao status de revogação. O IAM Roles Anywhere não oferece suporte a retornos de chamada para endpoints CRL Distribution Points (CDPs) ou Online Certificate Status Protocol (OCSP).

Outra consideração, não específica ao IAM Roles Anywhere, é garantir o armazenamento seguro das chaves privadas no servidor com as permissões apropriadas do sistema de arquivos.

 

Conclusão

Neste post, demonstramos como o novo serviço IAM Roles Anywhere ajuda você a permitir que workloads fora da AWS interajam com as APIs da AWS de forma segura e conveniente. Quando você estende os recursos das IAM Roles para seus servidores, containers ou aplicações executadas fora da AWS, você pode eliminar a necessidade de credenciais de longo prazo da AWS, o que significa que não há mais esforços desnecessários de distribuição, armazenamento e rotacionamento.

Mencionei alguns dos casos de uso comuns do IAM Roles Anywhere. Você também aprendeu sobre o processo de configuração e como usar o IAM Roles Anywhere para obter credenciais de curto prazo.

Este artigo foi traduzido do Blog da AWS em Inglês.

 


Sobre o autor

Faraz Angabini é especialista sênior em segurança na AWS. Ele ajuda os clientes estratégicos da AWS em sua jornada para a nuvem. Seus interesses incluem segurança, gerenciamento de identidade e acesso, criptografia, rede e infraestrutura.

 

 

 

 

Revisor

Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 14 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.

 

 

 

 

Dan Rezende atualmente é Senior Technical Trainer no time da AWS LATAM. Ministra treinamentos diversos nos domínios de Arquitetura, Segurança e Migração. Dan também tem experiência prática, já trabalhou em diversos projetos implementando soluções e arquiteturas para suportar diversos workloads de missão crítica como SAP e apoiando projetos de migração, enquanto atuou como arquiteto no time de Serviços Profissionais antes de entrar para o time de Treinamento e Certificação.