Permissões para AssumeRole, AssumeRoleWithSAML e AssumeRoleWithWebIdentity

A política de permissões da função que está sendo assumida determina as permissões para as credenciais de segurança temporárias retornadas por AssumeRole, AssumeRoleWithSAML e AssumeRoleWithWebIdentity. Você define essas permissões quando cria ou atualiza uma função.

Você também pode transmitir as políticas de sessão gerenciadas ou em linha como parâmetros das operações de API AssumeRole, AssumeRoleWithWebIdentity ou AssumeRoleWithSAML. As políticas de sessão limitam as permissões para a sessão de credencial temporária da função. As permissões da sessão resultante são a interseção da política baseada em identidade da função e das políticas de sessão. Você pode usar as credenciais temporárias da função em chamadas subsequentes à API da AWS para acessar recursos na conta que possui a função. Você não pode usar políticas de sessão para conceder mais permissões do que as permitidas pela política baseada em identidade da função que está sendo assumida. Para saber mais sobre como a AWS determina as permissões efetivas de uma função, consulte Lógica da avaliação de política.

As políticas que são anexadas às credenciais que fizeram a chamada original para o AssumeRole não são avaliadas pela AWS ao tomar a decisão de autorização "permitir" ou "negar". O usuário fornece temporariamente suas permissões originais em favor das permissões atribuídas pelo função assumida. No caso das operações de API AssumeRoleWithSAML e AssumeRoleWithWebIdentity, não há políticas para avaliar porque o chamador da API não é uma identidade da AWS.

Exemplo: atribuição de permissões usando AssumeRole

Você pode usar uma operação de API AssumeRole com diferentes tipos de políticas. Veja a seguir alguns exemplos.

Política de permissões da função

Neste exemplo, você chama a operação de API AssumeRole sem especificar a política da sessão no parâmetro Policy opcional. As permissões atribuídas às credenciais temporárias são determinadas pela política de permissões da função que está sendo assumida. O exemplo a seguir de política de permissões concede à função permissão para listar todos os objetos contidos em um bucket do S3 chamado productionapp. Ele também permite que a função obtenha, adicione e exclua objetos dentro desse bucket.

exemplo Exemplo de política de permissões da função

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::productionapp"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::productionapp/*"
    }
  ]
}

Política de sessão transmitida como parâmetro

Imagine que você deseja permitir que um usuário assuma a mesma função do exemplo anterior. No entanto, neste caso, você deseja que a sessão de função tenha permissão apenas para obter e colocar objetos no bucket productionapp do S3. Você não deseja permitir que ele exclua objetos. Uma forma de conseguir isso é criar uma nova função e especificar as permissões desejadas nessa política de permissão da função. Outra forma de fazer isso é chamar a API AssumeRole e incluir políticas de sessão no parâmetro opcional Policy como parte da operação de API. As permissões da sessão resultante são a interseção das políticas baseadas em identidade da função e das políticas de sessão. As políticas de sessão não podem ser usadas para conceder mais permissões do que as permitidas pela política baseada em identidade da função que está sendo assumida. Para obter mais informações sobre as permissões de sessão da função, consulte Políticas de sessão.

Depois de recuperar as credenciais temporárias da nova sessão, você pode transmiti-las para o usuário que você deseja que tenha essas permissões.

Por exemplo, imagine que a seguinte política é transmitida como um parâmetro da chamada de API. A pessoa que usa a sessão tem permissões para executar apenas as seguintes ações:

• Listar todos os objetos no bucket productionapp.

• Obter e colocar objetos no bucket productionapp.

Na política de sessão a seguir, a permissão s3:DeleteObject é filtrada e a sessão assumida não recebe a permissão s3:DeleteObject. A política define o máximo de permissões para a sessão da função de forma que ele substitui todas as políticas de permissões existentes na função.

exemplo Exemplo de política de sessão passada com a chamada da API AssumeRole

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::productionapp"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::productionapp/*"
    }
  ]
}

Política baseada em recurso

Alguns recursos da AWS dão suporte às políticas baseadas em recursos, e essas políticas fornecem outro mecanismo para definir permissões que afetam credenciais de segurança temporárias. Apenas alguns recursos, como buckets do Amazon S3, tópicos do Amazon SNS e filas do Amazon SQS oferecem suporte a políticas baseadas em recurso. O exemplo a seguir expande os exemplos anteriores usando um bucket do S3 denominado productionapp. A política a seguir é anexada ao bucket.

Quando você anexa a seguinte política baseada em recurso ao bucket productionapp, todos os usuários ficam impedidos de excluir objetos do bucket. (Consulte o elemento Principal na política). Isso inclui todos os usuários da função assumida, mesmo que a política de permissões da função conceda a permissão DeleteObject. Uma declaração explicita Deny sempre tem precedência sobre uma instrução Allow.

exemplo Exemplo de política de bucket

{
  "Version": "2012-10-17",
  "Statement": {
    "Principal": {"AWS": "*"},
    "Effect": "Deny",
    "Action": "s3:DeleteObject",
    "Resource": "arn:aws:s3:::productionapp/*"
  }
}

Para obter mais informações sobre como vários tipos de políticas são combinados e avaliados pela AWS, consulte Lógica da avaliação de política.