Examkin

Soru

Zorluk: OrtaMulti-Account Identity and Access Management Federation

A software development company is setting up federated access for its development teams to access multiple AWS accounts within an AWS Organization. The developer identities are managed in an external OpenID Connect (OIDC) compliant identity provider. A Solutions Architect registers the OIDC provider as an IAM Identity Provider in each target member account and creates an IAM role named DeveloperRole in those accounts with appropriate permissions. However, when developers attempt to authenticate using the OIDC provider and assume the DeveloperRole, the requests fail. Upon reviewing the configurations, the architect finds that the IAM roles cannot be assumed via OIDC. Which of the following is the most likely configuration error causing this issue?

  1. The trust policy of DeveloperRole in the member accounts specifies the sts:AssumeRole action instead of the sts:AssumeRoleWithWebIdentity action.Cevap
  2. B
    The Solutions Architect attached a Service Control Policy (SCP) to the Organizational Unit (OU) containing the member accounts to grant the federated users access to DeveloperRole, assuming the SCP would override the need for local role trust policies.
  3. C
    The trust policy of DeveloperRole in the member accounts specifies the sts:AssumeRoleWithSAML action instead of the sts:AssumeRoleWithWebIdentity action.
  4. D
    The trust policy of DeveloperRole references the OIDC provider as an AWS service principal under the Principal block instead of specifying the federated provider's ARN.

Cevap

The trust policy of DeveloperRole in the member accounts specifies the sts:AssumeRole action instead of the sts:AssumeRoleWithWebIdentity action.
The correct answer states that the trust policy of DeveloperRole in the member accounts specifies the sts:AssumeRole action instead of the sts:AssumeRoleWithWebIdentity action. To assume a role using OpenID Connect (OIDC) web identity tokens, the target role's trust policy must trust the registered OIDC provider ARN under the Federated principal and allow the sts:AssumeRoleWithWebIdentity action. Using sts:AssumeRole will fail because it expects AWS security credentials, which federated developers do not possess during the initial token exchange.

Adım Adım Çözüm

1
Analyze the authentication flow for federating external OpenID Connect (OIDC) identities into target AWS accounts.
Identified that developers use an external OIDC provider and need to assume DeveloperRole in target member accounts via OIDC tokens.
Understanding the entry point of federation helps isolate whether AWS STS expects a SAML assertion, an OIDC token, or standard AWS credentials.
2
Verify the STS action required in the trust policy for OIDC-based federation.
OIDC federation requires the sts:AssumeRoleWithWebIdentity action in the trust policy of the target role.
The standard sts:AssumeRole action is reserved for cross-account or service-based role assumption using AWS credentials, whereas OIDC tokens require sts:AssumeRoleWithWebIdentity.
3
Examine the role trust policy's Principal configuration for OIDC identity provider integration.
The trust policy must declare the federated OIDC provider's ARN under the Principal's Federated key.
Using an incorrect principal configuration (such as an AWS service principal or missing the Federated key) breaks the trust chain between AWS STS and the OIDC IdP.

Anahtar Kavram

To establish federation with an external OpenID Connect (OIDC) identity provider, target IAM roles must have a trust policy that permits the sts:AssumeRoleWithWebIdentity action and references the OIDC provider ARN under the Federated principal.
Tahmini Süre:1m 30s
Bu soruyu puanla

Konular

Multi-Account Identity and Access Management Federation

Bu konudan daha fazla soru