I have an EKS instance located in an account A. From an account B I have two roles, former for S3 access in the account B and latter for dynamodb access in the account B. These roles have trusted relationships with the account A.
Is it possible to have simultaneous access to these resources in account B from the EKS located in the account A?
Also, I must have access to resources in the account A: S3 and dynamodb.
So, a single pod in the EKS (in the account A) must have these accesses:
Access to S3 in the account B with a dedicated trusted role in the account B
Access to DynamoDB in the account B with a dedicated trusted role in account B
Access to some resources in the account A
Can I organize that without rearranging roles in the account B?
Yes, there's a way to assume multiple roles at the same the but it'll not be the union of permissions of both because when you assume role you get the temporary credentials. And requests made with these temporary credentials are authorized against the permissions granted to that role.
Every request is performed by a single principal, so if you are trying to perform a single action that requires the union of the permissions of multiple roles, that's a not possible.
Related
I have one organization with multiple sub accounts. I would like to create IAM Policies that grant users full administrator access to any resources in specific sub account (or sub accounts). How can this be achieved?
From an AWS Organization perspective, you have control over the accounts and resources via Service Control policies (SCPs).
"However, an SCP never grants permissions. Instead, SCPs are JSON policies that specify the maximum permissions for the affected accounts."
With that in mind, you can't grant users full administrator access to any resources in a specific subaccount(s) using AWS Organization and AWS IAM Policies only.
This leads us to (roughly) 3 paths:
By default, if you create a member account as part of your organization, AWS automatically creates a role in the account that grants administrator permissions to IAM users in the management account who can assume the role.
The IAM Role in question is OrganizationAccountAccessRole. You can customize its name and use it to grant your users full administrator access across all the resources inside the AWS account.
See: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html
Observations: Since this IAM Role is created in every account. You would need to intervene and limit the IAM Cross-Account access manually in each sub-account.
You can use AWS CloudFormation StackSets to deploy across multiple AWS accounts a list of IAM Roles your users could use for admin purposes (eg RoleFullAdmin, RoleReadOnly, RoleDevOps), and AWS Organizations enables you to create stack sets with service-managed permissions, using a service-linked role that has the relevant permission in each member account.
From your AWS Organizations management account (or delegated administrator account) you can deploy Stack Sets to current accounts and they are automatically deployed to every new account your create, keeping your resources in sync.
You can target accounts via account ID or organizational units (OUs).
See: https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html
Observations: Similar to 1, since you are using IAM Role Cross-Account access, you need to manually intervene in the policy trust relationship.
Add AWS IAM Identity Center (successor to AWS Single Sign-On) to your AWS Organizations
What you are looking for can be achieved by Permission Sets in the AWS IAM Identity Center.
You can customize the access per user and have a many-to-many relationship between User <-> Accounts <-> Roles. You can define one or more IAM Policies in the Permission Set.
AWS provides predefined permissions that you can use too.
See: https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html and https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetpredefined.html
Observations: You need to add an extra resource to your AWS Organization and configure the identity source of your users. This also requires a change in the process of "how to login to our aws account". Now you need to use the AWS SSO etc.
We’re trying to implement Redshift with authentication via SAML.
In our case, we have many AWS accounts and the Redshift cluster is in one of them. We need to viabilize the access via roles from these accounts to the one that hosts the cluster. Discarding the necessity of having to manage user/password.
The way we implemented it’s already possible to login using IAM roles, but we still need the cross-account.
Does anyone knows if it's possible ?
Since you already have signin working with IAM roles, the process would be:
Amazon Redshift in Account-A
IAM Role (Role-A) in Account-A that has:
Permission to access Redshift via IAM (I think it's just permission to call GetClusterCredentials?)
A Trust Policy allowing the Role to be assumed by specified other accounts (or specific roles in those accounts)
Other accounts wanting to access Redshift will:
Call AssumeRole() to assume Role-A
Use the returned temporary credentials to access Redshift using Role-A
Thus, Redshift only ever sees a login being requested from Account-A.
As per AWS documentation here - You cannot switch roles when you sign in as the AWS account root user.
If we go by AWS best practices i.e. not to use root user to perform actions, this restriction makes sense & supports why AWS does not allow role switch as root user. However, when using a Bucket policy, a root user in one account can access a Bucket in another account & AWS does not seem restricting that unlike roles (Technically, both are cross account actions using resource policies).
Why does this 'root user restriction' apply only for roles and not buckets - Any security reasons?
Access to services is normally granted via IAM permissions on IAM Users, IAM Groups and IAM Roles.
Some AWS services also permit the creation of policies that can grant access to aspects of that specific service. Examples are:
Amazon S3 bucket policies
Amazon SQS queue access policies
Amazon SNS access policies
These policies can be used to grant cross-account access, and also unauthenticated access such as public access to objects in Amazon S3 buckets and the ability to send unauthenticated messages to an Amazon SQS queue.
These policies are used to grant additional access. They do not involve "assuming" any additional roles.
I think there is some misunderstanding on the use of roles and a bucket policy with external account's root as principle.
The roles are meant to be temporary assumed, for someone or something that normally does not have permissions for some action. This could be a user or service from same or different account.
However, when you use other account's root in a bucket policy principle, you are giving that account permanent (until manually revoked by you) trust to the bucket for all or some actions on it. You use root as the principle so that the owner of the other account can delegate access to its own users or roles. You fully trust the other account to manage the access to the bucket without your involvement.
Off course if you are not comfortable giving such trust to the other account, you can limit access to you bucket to a given IAM user or a role only. This will obviously limit the ability of the owner of the other account to delegate access to your bucket.
I have the following scenario:
We are build an infrastructure on AWS with infrastructure as code (IAC) on multiple accounts.
I have account A and account B in the beginning, and I want to create the infrastructure in both using CloudFormation and Terraform. When account A is created, I want to allow a role in account B to have access to a S3 bucket, that is created in account A. The role in account B is not yet created, however, I do know, what the name is eventually going to be.
My question: Can I grant access to non-existing resources between both accounts, if I do know how they are going to be named eventually?
OR: Do I have to create the resources before I can grant the access?
Stack Sets would allow you to run manage stacks in multiple accounts and regions with CloudFormation. CloudFormation is pretty smart about dependencies, but you can explicitly use the DependsOn attribute to have resources wait for the dependent resource to be ready, like the IAM Role for cross-account access in this case.
I have seen in earlier posts that I can restrict access to S3 bucket using the EC2 instance IAM Role. But the catch here is, if I have an account with several users in it, I cannot restrict the use of an IAM role to a particular group or individuals within that account. This inability prevents me from blocking anyone in that account to spin an instance using that IAM role.
So my dilemma is, if I have given S3 access based on EC2 Role and cannot lock down the users within an account who can use that role, this opens my S3 bucket to everyone in the account.
Please let me know if there is a way I can, either
(1) Restrict EC2 instances getting spun up using a particular role, OR,
(2) Restrict S3 access based on EC2 Role AND user logged into the instance.
Launching an Amazon EC2 instance with an assigned requires the PassRole permission, which can further specify which roles can be passed to the instance.
By default, you should not give anybody the PassRole permission. You could then assign it to appropriate Users/Groups, specifying exactly which roles they can use.
This avoids the chance that a User within limited permissions can gain extra permissions by launching an instance with a Role, and then using the temporary credentials granted to the instance to do activities beyond their assigned permissions.
This is similar to the AssumeRole permission, which controls who is allowed to assume which roles.
For more information, see: Granting Permission to Launch EC2 Instances with IAM Roles (PassRole Permission)