I have Role A. Role A is denied access to Item X.
Then there is Role B.
Role B should be granted access to Item X.
Role B is Member of A.
So a user that is in Role A should not have Access. And a user that is in Role B should have access.
I have seen that deny cant be overwritten, is there a workaround?
I need to set the rights in code behind.
Thanks
You should make use of Sitecore's inheritance. On role A you can deny inheritance on role A, while allowing the access on role B.
More information on security can be found here
Related
Account A 1234567890 has granted account B 0987654321 access to an a bunch of AWS services through a certain role:
arn:aws:iam:1234567890:role/bunch_of_access
And there's another account C that is owned by the same owner as B that needs the same role access but can't get it through account A.
Is there a way for account B to allow account C to also use the arn:aws:iam:1234567890:role/bunch_of_access role?
Or is there a way to create a new role that let account C access root role from account B to get the access to arn:aws:iam:1234567890:role/bunch_of_access ?
Yes, you can do this with role chaining.
An entity in account C can assume a role in account B, and then using the assumed role it can assume the required role.
More on role chaining: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html
I am new to AWS and trying to understand IAM. I have a doubt which goes like this. for example there is a s3 bucket in account A and in it's resource policy another AWS account B (root user) is given permission for a certain set of actions. Now there are certain roles which are also present in account B. so if someone assumes those roles, will they also have access to that s3 bucket in account A or the Arn of that role needs to be explicitly mentioned in the resource policy of bucket even though it's root account already has access to it ?
When you want to provide access cross-accounts, that is - access to a resource in one account to a principal (in this example, a role) from another account - granting the access on the resource policy is not enough - and you also have to give access to that principal in a IAM policy in its account. When you place the root user of an account in a resource based policy - that indicates that access may be granted to any principal within that account (using a IAM policy on that account)
So, to answer your question - if the root user of account B is a principal to which access is granted in the bucket policy - you don’t have to indicate the ARN of any specific role - However, you do need to assign access to the role in a IAM policy in account B so assuming it would grant access to the bucket (I’m assuming there’s no mechanism denying the access of course)
When a user assumes a role, the user temporarily gives up his or her original permissions in exchange for those granted by the role. So to answer your question, in order for the bucket to be accessible to the role assumed by the root account (or any principle really), the ARN of the role needs to be explicitly mentioned in the bucket policy.
In aws an IAm user can be given say read access to an s3 bucket using permissions. Similarly a policy (permission) can be attached to an s3 bucket to allow certain user access to that s3 bucket. My question is why there are two ways to do it. Should you define both? What if user 1 is allowed to access an s3 folder but IAM policy at resource level allows user 2 access to it. Who wins in this situation? What is the order of evaluation?
Typically:
To grant Amazon S3 access to a specific user, it is best to place the policy on the IAM User (or an IAM Group container IAM Users).
To grant public access, place a Bucket Policy on the bucket permitting anonymous access.
Yes, it is possible to grant individual access via a Bucket Policy, but this can become quite messy if multiple users are added this way.
The user will be permitted to access the bucket as long as either of these methods are used. However, any Deny policy will always override an Allow policy from either source.
After setting up AWS Organizations, I created a member account with a custom IAM role name. I've now forgotten the role name used and I'm unable to assume role as root into that account. I need to create IAM users in the member account but without the ability to assume role using the custom OrganizationAccountAccessRole it seems I'm unable to.
I've tried getting access by
Using the member account root user but it doesn't have permissions to IAM
Signing in to member account using AWS SSO user with IAMFullAccess and AdministratorAccess policies attached to the policy set but user cannot access IAM.
Attempting to describe member account using the master account admin user but the role isn't there
At this point, I'm thinking the only way out is to recreate the member account. Please tell me there is a better way.
UPDATE:
- Found that 1 & 2 didn't work because of a restrictive Service Control Policy (SCP) on the account which didn't include IAM access permissions.
Based on the comments.
The solution was to inspect CloudTrial logs to find the API call used to create the role.
So this is what i want to do -
I have 3 different accounts - account A, account B and account C.
I start in a role in account A. This role is allowed to assume another role in account B. This role in account B is allowed access to describe s3 buckets in account C.
This is where my question comes in. Will i be able to describe the buckets in account C by first assuming a role in account B. Then using this credential, assume a role in account C to describe 3 buckets?
I was thinking of possibly using STS twice. Would this be viable ? i do realise this was possible with two accounts in another question. But would this be possible from three different accounts ?
something like the example in this question would work ?
How to assume an AWS role from another AWS role?
My doubt comes to the place where would the account is being sent to account C be that of account A or account B?
Account C currently has the role to allow only account B to assume it. And account B has a role that only allow account A to access it.
Yes. You can assume a role from an assumed role.
Account C would have a role that trusts account B. Account B would have a role that trusts account A.
Each role would also have to have permissions for sts:AssumeRole on the role that account is assuming.
Account A's role can sts:AssumeRole on Account B's role, and trusts EC2 or your IAM user or whatever.
Account B's role can sts:AssumeRole on Account C's role, and trusts Account A.
Account C's role can s3:ListBuckets and trusts Account B.
When you assume a role, you give up your current identity and permissions and assume a new identity and new permissions - not additional permissions.
If your goal is to have access to three buckets, then your assumed role needs access to those three buckets.