Let's say, I have an user, say User-A, that is assigned the following policy (who is essentially an admin user):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
Can I create another policy and associate it to User-A, so that User-A can't launch EC2 instance? (I don't want to disassociate the above policy from User-A; because of some legacy reason, I only want to add rules/policies to a user)
Moreover, can I limit launching EC2 instance operation from an AWS account root user? (See the following statement on AWS IAM page)
When you sign in as the root user, you have complete, unrestricted
access to all resources in your AWS account, including access to your
billing information and the ability to change your password.
If you can edit the existing policy, then you can change the permissions that are being granted (eg by using NotAction, as #bishop suggested).
If you cannot edit the existing policy, you can add another policy with "Effect": "Deny" and then list the actions that are not permitted.
As to the Root account... It can basically do anything. That is why the recommendation is to attach Multi-Factor Authentication to the account, then lock away the MFA device for emergency use only.
Related
I have some roles in my Dev account that has not been used for over 90days and I would like to disable those role for now without deleting them.
please how do i write the policy that i can attach to those roles that will deny all actions to all resources in AWS account.
To temporarily disable a user, you can go via 2 options which i'll outline below:
Apply a restrictive IAM policy
Disable their console and access keys to AWS
Option 1:
Explicit denies applied via AWS IAM policies overrides any allow permissions:
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
Remember, an explicit deny in any of these policies overrides the allow.
So your newly attached policy should just include a deny all for all resources and actions:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllActions",
"Effect": "Deny",
"Action": "*",
"Resource": "*"
}
]
}
Option 2:
Although another thing you can do is disable the IAM keys and remove console access so that you effectively disable the user without applying any restrictive permissions:
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html
To disable an active access key, choose Make inactive.
https://docs.aws.amazon.com/IAM/latest/UserGuide/console_controlling-access.html
You can disable user access to the AWS Management Console by removing their password. This prevents them from signing into the AWS Management Console using their user name and password
I created some SQS queues as a root user. - Now when I like to restrict access via policies it does not seem to work. - Even with a test policy like this
{
"Version": "2008-10-17",
"Id": "PolicyDenyTest",
"Statement": [
{
"Sid": "DenyIt",
"Effect": "Deny",
"Principal": "*",
"Action": [
"sqs:DeleteMessage",
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:us-west-2:xxxxxxxxxx:TST"
}
]
}
I can still send/retrieve/delete messages from the queue from my local machine. - Are policies only valid when creating queues with an IAM user?
The credentials of the account owner allow full access to all resources in the account. You cannot use IAM policies to explicitly deny the root user access to resources. You can only use an AWS Organizations service control policy (SCP) to limit the permissions of the root user. Because of this, we recommend that you create an IAM user with administrator permissions to use for everyday AWS tasks and lock away the access keys for the root user.
https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html
The root key is all-powerful key that can be used to recover everything even if you mistakenly deny all access to all your resources. This is a well thought-out decision that is explained in the linked doc
I am trying to create an IAM user and I want to assign the user for Full S3 Access using IAM role (via console access). I know I can do that using Group or attaching the S3FullAccessPolicy directly to the user. I am unable to do this and could not find any help regarding this. The articles I come across describes how you can attach IAM policies to EC2 instance etc.
I managed to create a role and attached a trust policy as below. I also attached the policy "AmazonS3FullAccess" to the role.
But it never worked if I login using AWS management console (browser). It still denies all permission to the user for S3 access. The trusted entities policy looks like below - the IAM username I am trying to use is s3AdminUserWithRole. Th eAWS account id is 6XXXXXXXXXXX0
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::6XXXXXXXXXXX0:user/s3AdminUserWithRole",
"arn:aws:iam::6XXXXXXXXXXX0:root"
]
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
Is it not possible to do like this for AWS Management console for a user? We have to use only Groups /managed policies/ inline policies and NOT roles for this? Confused about the AWS documentation then.
Based on the comments, the solution is to use sts service and its assume-role API.
For Console there is Switch Role option.
I have an application where I am using Cognito to authenticate users and giving temporary access to AWS Console but that user is able to see all other buckets, I want that user just should be able to see or access buckets created by him.
Currently, I have given S3FullAccess Policy to Cognito users. Can anyone suggest which policy I should attach?
As per my R&D, I can some policies are there that can restrict particular user or allow particular user but my users will be dynamic, so I cannot hard-code the values and also policies like allowing/restricting access to particular buckets, I want only users who create buckets should be able to access not other users.
This is something which i found
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::bucket-name",
"Condition": {
"StringLike": {
"s3:prefix": [
"",
"home/",
"home/${aws:userid}/*"
]
}
}
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::bucket-name/home/${aws:userid}",
"arn:aws:s3:::bucket-name/home/${aws:userid}/*"
]
}
]
}
But this is listing all buckets and the only accessible bucket is what put in the code above, I want for new user, it should show nothing and as it creates, it should show that only
This is not going to be easy and you will need to create your own policy and enforce some conventions. You have 3 options.
But first, if each user just needs their own S3 space look at S3 Prefix [here](
https://aws.amazon.com/blogs/mobile/understanding-amazon-cognito-authentication-part-3-roles-and-policies/) Also, you can do this on the S3 resource bucket. I have a template for doing this here in gitlab
Now back to answering your question.
Option 1; They will need to set a tag when they create the bucket where an "owner" tag is equal to their identity. I striked this one out because despite being listed in the IAM policy I'm pretty sure it doesn't work with S3.
Option 2: The prefix of the bucket name is equal to their identity.
Then you can use the feature of variables and tags in IAM Policy. Read here
Note that coginto users are web federated identities so the variable aws:username is not aviable for you. Use the aws:userid variable and the value will be role id:caller-specified-role-name where role id is the unique id of the role and the caller-specified-role-name is specified by the RoleSessionName parameter passed to the AssumeRoleWithWebIdentity request
Option 3: Use IAM Access Policy
I can not find a link to the how to at the moment. But from here is a detailed description.
Q: How do I control what a federated user is allowed to do when signed in to the console?
When you request temporary security credentials for your federated
user using an AssumeRole API, you can optionally include an access
policy with the request. The federated user’s privileges are the
intersection of permissions granted by the access policy passed with
the request and the access policy attached to the IAM role that was
assumed. The access policy passed with the request cannot elevate the
privileges associated with the IAM role being assumed. When you
request temporary security credentials for your federated user using
the GetFederationToken API, you must provide an access control policy
with the request. The federated user’s privileges are the intersection
of the permissions granted by the access policy passed with the
request and the access policy attached to the IAM user that was used
to make the request. The access policy passed with the request cannot
elevate the privileges associated with the IAM user used to make the
request. These federated user permissions apply to both API access and
actions taken within the AWS Management Console.
The nice thing about this approach is you programmatically create the access policy.
The policies attached to the IAM developers group I've set up are as follows:
However, launching new instances won't work. Just after a user in this group selects the key pair to associate with it, i.e. reaches the final step, they get the following message on the next page:
Launch Failed
You are not authorized to perform this operation. Encoded authorization failure message: WZzytnkJ4T3-nkMYslM...
What's preventing developers to launch new instances, given these policies?
It could be that the instance is being launched with an IAM Role, and the group does not have iam:PassRole permissions (which are outside of the ec2:* permissions space).
You should add a policy like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PassRoleToEC2",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*"
}
]
}
This saying "Allow this user to pass any (*) role to an EC2 instance".
Actually, you should limit such permissions only to specific roles, otherwise a normal user could select an Admin role. Then, if they logged into the instance, they would have access to credentials that have Admin permissions on the whole AWS Account.
Alternatively, do not select a Role when launching the instance. It should then launch okay (assuming that this is the issue causing the error).
The user needs a PassRole permission.
A Role must be associated with the "Launch" of the EC2 instance.
The PassRole permission helps you make sure that a user doesn’t pass a role to an EC2 instance where the role has more permissions than you want the user to have.
As in the following example, if the EC2 Launch requires access to S3 you User must be able to pass the S3 role required.
{
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::123456789012:role/S3Access"
}
Link to documentation:
https://aws.amazon.com/blogs/security/granting-permission-to-launch-ec2-instances-with-iam-roles-passrole-permission/