Anotações sobre o AWS IAM para ajudar na preparação das certificações AWS.

Até o momento as anotações são para as certificações abaixo:

• Link oficial
• FAQ

Anotações gerais

• Controle de acesso para recursos
• Serviço Global
• Analise de acesso
• Por padrão um usuário não tem permissões - tudo negado por padrão

Service Roles

Uma Service Role é uma Role que um serviço da AWS assume para executar ações em seu nome.

Referências

• IAM service roles

PassRole

PassRole é uma permissão concedida a usuários e recursos do IAM que permite que eles usem uma Roles do IAM.

• Não é possível utilizar a permissão PassRolepara passar uma função entre contas.

Exemplo da PassRole

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "iam:GetRole",
            "iam:PassRole"
        ],
        "Resource": [
            "arn:aws:iam::<account-id>:role/EC2-WordpressRole",
            "arn:aws:iam::<account-id>:role/EC2-DatabaseRole"
        ]
    }]
}

Referências

• Granting a user permissions to pass a role to an AWS service
• Understanding IAM PassRole
• Introdução a AWS AssumeRole, PassRole e Service-Linked Roles

Permission Boundary

Documentação oficial

A AWS oferece suporte a Permission Boundary para entidades (_Users ou Roles) do IAM. Um Permission Boundary é um recurso avançado para usar uma política gerenciada para definir as permissões máximas que uma política baseada em identidade pode conceder a uma entidade do IAM. O limite de Permission Boundary permite que a entidade execute somente as ações permitidas por ambas as políticas baseadas em identidade e seus limites de permissões._

• Permission Boundary sozinho não dá acesso a permissão, é necessário que ambas as permissões (Policies e Boundary) estejam configuradas
• Só pode ser configurado uma Police por vez, caso seja necessário mais, tem que criar uma Police customizada

MFA

• Virtual MFA Devices (Google Autenticator or Authy)
• Universal 2nd Factor (U2F) Security Key - Phisical Device
• Hardware Key Fob MFA Device
• Hardware Key Fob MFA Device for AWS GovCloud (US)

Exemplo Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:user/anika" },
      "Action": "sts:AssumeRole",
      **"Condition": { "Bool": { "aws:multifactorAuthPresent": true** } }
    }
  ]
}

IAM Users

• Users
• Podemos ter um usuário em mais de um grupo

IAM Roles

Documentação oficial

Uma Role do IAM é uma identidade do IAM que você pode criar em sua conta com permissões específicas. Uma Role do IAM é semelhante a um usuário do IAM, pois é uma identidade da AWS com Policies de permissão que determinam o que a identidade pode e não pode fazer na AWS.

• Identidades que podem assumir
• Assumidas temporária
• Permissões associadas
• Não podem ser utilizadas por usuários, somente por AWS Services
• IAM Users, App e AWS Services podem assumir IAM Roles
• Use IAM Policy para permissões

Tipos de AssumeRole

AssumeRole
– Retorna um conjunto de credenciais de segurança temporárias que você pode usar para acessar recursos da AWS aos quais você normalmente não tem acesso.

• As credenciais temporárias consistem em Access Key, Secret Access, and Security Token.
• Normalmente, você usa AssumeRole em sua conta ou para acesso entre contas.
• Pode incluir informações de autenticação multifator (MFA) ao chamar AssumeRole .
• Isso é útil para cenários entre contas para garantir que o usuário que assume a função tenha sido autenticado com um dispositivo AWS MFA.

AssumeRoleWithSAML

• Retorna um conjunto de credenciais de segurança temporárias para usuários que foram autenticados por meio de uma resposta de autenticação SAML.
• Isso permite que você vincule seu armazenamento ou diretório de identidade corporativa ao acesso baseado em função da AWS sem credenciais ou configurações específicas do usuário.

AssumeRoleWithWebIdentity

• Retorna um conjunto de credenciais de segurança temporárias para usuários que foram autenticados em um aplicativo móvel ou da Web com um provedor de identidade da Web.
• Provedores de exemplo incluem Amazon Cognito, Login with Amazon, Facebook, Google ou qualquer provedor de identidade compatível com OpenID Connect.

IAM Groups

• Agrupamentos de usuários com permissões em comum
• Grupos só tem usuários e não pode ter outros Grupos

IAM Authorization

IAM Authentication

AWS Policy Evaluation Logic

Documentação oficial

• Deny explicito sobrepõe Allow

Resource-based policies

Documentação oficial

• A Resource-based policies permite anexar uma política diretamente ao recurso que você deseja compartilhar, em vez de usar uma função como proxy.
• A Resource-based policies especifica que o Principal, na forma de uma lista de números de ID de conta da AWS, pode acessar esse recurso e o que eles podem acessar.
• Usando o acesso entre contas com uma política baseada em recursos, o usuário ainda trabalha na conta confiável e não precisa abrir mão de suas permissões de usuário no lugar das permissões de função.
• Os usuários podem trabalhar nos recursos de ambas as contas ao mesmo tempo e isso pode ser útil para cenários como, por exemplo, copiar objetos de um bucket para outro
• As Resource-based policies precisam da conta confiável para criar usuários com permissões para poder acessar os recursos da conta confiável.
• Somente permissões equivalentes ou inferiores às permissões concedidas à sua conta pela conta proprietária do recurso podem ser delegadas

Os recursos que você deseja compartilhar são limitados a recursos que dão suporte a Resource-based policies

• O S3 permite definir a política do bucket para conceder acesso ao bucket e aos objetos
• Simple Notification Service (SNS)
• Simple Queue Service (SQS)
• Glacier Vaults
• OpsWorks stacks
• Lambda functions

Referências

• Jayendra Blog - AWS IAM Roles vs Resource Based Policies
• How IAM roles differ from resource-based policies

External ID

Documentação oficial

Por que usar um External ID?
O External ID permite que o usuário que está assumindo uma Role assegure as circunstâncias nas quais elas operam.
Também oferece uma forma para o proprietário da conta permitir que a Role seja assumida apenas em determinadas circunstâncias.
Às vezes, é necessário oferecer acesso a terceiros para os recursos da AWS (delegar acesso).
Um aspecto importante desse cenário é o External ID, informação opcional que você usa em uma trusted policy da Role do IAM para designar quem pode assumir a Role.

• Informar o --external-id "xxxx" via CLI ou API
• Quando criar uma Role do tipo "Another AWS Account" é opcional o ExternalId, porém é altamente recomendado e é uma boa pratica. Caso selecionado, deve-se informar o External ID.

Exemplo Policy

    "Principal": {"AWS": "AWS Account ID"},
    "Condition": {"StringEquals": {"sts:ExternalId": "XXXX"}}

Referências

• Securely Using External ID for Accessing AWS Accounts Owned by Others

Best Practices

Documentação oficial