I am playing with AWS IAM and have the following scenario:
I have different projects for which I am collaborating with other people. I have a user group (IAM) project_x_admin to which user_x is assigned. Next to user_x, user_y and user_z are existing as well.
I now added policies to this group to allow those users to configure their SSH keys (e.g., to use within AWS CodeCommit) as described over here: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_my-sec-creds-self-manage-no-mfa.html.
Now, when I login as user_x and when I go to the users page (to go to my detail page, to configure the SSH key), I get the message that ListUsers is not granted for this user.
Question:
Is it possible to configure IAM to allow ListUsers with restricting the result set to only the logged in user? I already tried via Condition on tags, but until now, I only got or all users are visible or I get the message that the permission is not granted. Anyone knows how to fix this?
What I tried with Condition keyword:
{
"Sid": "AllowListItself",
"Effect": "Allow",
"Action": [
"iam:ListUsers"
],
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {
"aws:username": "${aws:username}"
}
}
}
And
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "iam:ListUsers",
"Resource": "*",
"Tags": [
{
"Key": "name",
"Value": "user_x"
}
]
}
And
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "iam:ListUsers",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/name": [
"user_x"
]
},
"ForAllValues:StringEquals": {"aws:TagKeys": "name"}
}
}
All these statements resulted in or all users visible or nothing.
Can anyone help me with this configuration?
The actual problem you are trying to solve is that you need to access your IAM account settings, and you can't get to it through the account list page due to permission issues.
The solution is to click your account name in the top-right section of the AWS console and a drop-down menu will appear. In that menu will be a link to "Security Credentials". Click that link and it will take you directly to your IAM account settings, where you can do things like upload SSH keys, and create API access keys.
I found out that the way to solve this, is to work with AWS Organizations in which you have an account per department or organization and a master account on top of it
Related
I'm currently managing a AWS SSO solution using it with AzureAD. For our use case we need to be able to revoke access/session of a user.
In AzureAD it's pretty simple, go to the user, block him, revoke its session. It's done, user needs to relog but he won't be able to do so.
In AWS SSO, it looks a bit harder, I can't seem to find a way to instantly revoke a session. I can disable its access, but once he has a session, even deleting the user/group from AWS SSO will not terminate the session.
This causes quite a problem as this is compliant to my security standards.
Any ideas?
Thanks people
An option is to put in place a temporary SCP on the AWS account to deny all actions for the Role session of the user as shown below:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "UserRestrictions",
"Effect": "Deny",
"Action": "*",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:userId": [
"AROAEXAMPLEROLEID:alice#example.com"
]
}
}
}
]}
After a day or so (or the max role duration) you could remove the SCP. This is useful if you only have a single role session but in the scenario of an AWS SSO user, the user probably has access to multiple Roles across multiple AWS accounts. Rather than adding multiple SCPs you could add a SCP higher up in the organizational hierarchy that denies actions for all Role sessions for the user as shown below:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "UserRestrictions",
"Effect": "Deny",
"Action": "*",
"Resource": [
"*"
],
"Condition": {
"StringLike": {
"aws:userId": [
"*:alice#example.com"
]
}
}
}
]}
I initially tried with all the json policies in the below link.
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/iam-identity-based-access-control-cwl.html#customer-managed-policies-cwl
And i finally got a solution of giving "list, read, write" access to one specific loggroup for an IAM user by using below JSON policy. But it is able to see the list of other log groups as well. As per the below JSON policy i tired limiting the resource for listing as well. It didn't work.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"logs:GetLogRecord",
"logs:DescribeLogGroups"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"logs:Describe*",
"logs:FilterLogEvents",
"logs:GetLogEvents"
],
"Resource": "arn:aws:logs:us-east-1:XXXXXXXXXXXX:log-group:/aws/lambda/XXXX:log-stream:*"
}
]
}
But then i found the tagging as a solution and tried tagging the loggroup and user with same tag and tried below JSON policy. That didn't work either.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"logs:*"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringLike": {
"logs:ResourceTag/Team": "Green"
}
}
}
]
}
Please can someone kindly suggest a way where i could give access to one specific IAM user for only one group to either, list&read or list,read&write. But that user should not be able to see the other log groups.
But it is able to see the list of other log groups as well
That's not something you can do typically within AWS. Generally IAM permissions can't affect on the result of an API action. It can't filter it to only show something in particular. This is one the reasons AWS recommends to isolate workloads by using different accounts, as API calls are only scoped to one account.
In this case, you can either not give access at all or give access to list everything.
I want to restrict access for a specific user to see just few EC2 instances. I created a new user in IAM Roles and I attached a new Policy to it. The content of that Policy is attached below. I tried to look over documentation and to do it myself like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": [
"arn:aws:ec2:eu-west-1:ACCOUNT_ID:instance/i-INSTANCE_ID1",
"arn:aws:ec2:eu-west-1:ACCOUNT_ID:instance/i-INSTANCE_ID2"
]
}
]
}
I placed my region,ACCOUNT_ID(the owner id, not of the new user created) and instance-id, but when I connect with that user and I go to list all Instances I got this An error occurred fetching instance data: You are not authorized to perform this operation..
After I placed the code in JSON editor, in Policy Review step I got this message:
This policy defines some actions, resources, or conditions that do not
provide permissions. To grant access, policies must have an action
that has an applicable resource or condition. For details, choose Show
remaining Learn more
The AWS documentation mention exactly the same configuration or these examples.
I assume you connect as that user in the console (but it would be the same with CLI) Here is what I think is happening:
To list all the instances, the console most probably calls the DescribeInstances API. As per the list of action/resources/tags that can be used in IAM policy, this API does not support the resource filter in IAM.
This means your user has no authorization to list instances and they will not be shown in the console. You can validate this theory by using the CLI to request the details of a specific instance id, if my hypothesis is correct, it will be authorized.
As DescribeInstances can not be restricted by resource or tags, I don't think it is possible to filter the instance list for a user.
To have the console working, you'll need to add the following statement in your IAM policy
"Statement": [
{ your existing statement },
{
"Effect": "Allow",
"Action": "ec2:DescribeInstances",
"Resource": "*"
}
]
Please report if I was right :-) The example you mentioned in your question shows exactly that : Resources = * on DescribeInstances and Resources specific InstanceId on other operations.
The previous answer is wrong, you can Conditionally allow access to ec2:DescribeInstances by tag names. It's an AWS best practice as well. Also explicitly deny access to the ec2:CreateTags and ec2:DeleteTags actions to prevent users from creating or deleting tags to take control of the instance.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DescribeInstances",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/UserName": "${aws:username}"
}
}
},
{
"Effect": "Deny",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Resource": "*"
}
]
}
DescribeInstances action does not support condition.
https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html
I have an AWS account that contains a set of autoscaling groups. I'd like one of my IAM users for that account to be able to see (just read-only ATM) the status of one particular autoscaling group in the IAM user's version of the web console. How do I do that? Right now, the autoscaling group is visible (and can be controlled) through the web console by the account's "root" user, but when the IAM user logs in to his/her specific IAM user account, the autoscaling console webpage shows that no autoscaling groups exist.
I've tried to give the specific IAM user policy permissions for various autoscaling API calls (e.g. autoscaling:Describe*, as described here), but that seems to have no impact on the web console for the IAM user, it remains empty (as if no autoscaling groups exist). Is there any other policy I need to give the IAM user permission for, or something else I need to do? Right now they have access to AmazonEC2ReadOnlyAccess and AutoScalingReadOnlyAccess, and some specific API calls so that the python API (boto) works.
You need to give it the AutoScalingConsoleReadOnly policy and not just the describe ... You may go to the Policies and there you will find the JSON for the policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeVpcs",
"ec2:DescribeVpcClassicLink",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSubnets"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "elasticloadbalancing:Describe*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:ListMetrics",
"cloudwatch:GetMetricStatistics",
"cloudwatch:Describe*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "autoscaling:Describe*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"sns:ListSubscriptions",
"sns:ListTopics"
],
"Resource": "*"
}
]
}
I have tried to limit access to a VPC without success. Maybe approaching the issue from the other side is a better idea, but I can't get that to work either.
I have tried:
Limit by tags as shown here:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/client": "<client>"
}
}
}
]
}
Limit by VPC as suggested here:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1508450090000",
"Effect": "Allow",
"Action": [
"ec2:Describe*"
],
"Resource": [
"arn:aws:ec2:<region>:<account>:subnet/*"
],
"Condition": {
"StringEquals": {
"ec2:Vpc": "arn:aws:ec2:<region>:<account>:vpc/<vpc_id>"
}
}
}
]
}
Both policies result in not even listing any instances, see screenshot.
This seems to be a very obvious and commonly needed policy to me.
Any help is appreciated.
According to the documentation: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_IAM.html#readonlyvpciam
The following policy grants users permission to list your VPCs and
their components. They can't create, update, or delete them.
{
"Version": "2012-10-17",
"Statement":[{
"Effect":"Allow",
"Action":["ec2:DescribeVpcs",
"ec2:DescribeSubnets",
"ec2:DescribeInternetGateways",
"ec2:DescribeEgressOnlyInternetGateways",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeNatGateways",
"ec2:DescribeCustomerGateways",
"ec2:DescribeVpnGateways",
"ec2:DescribeVpnConnections",
"ec2:DescribeRouteTables",
"ec2:DescribeAddresses",
"ec2:DescribeSecurityGroups",
"ec2:DescribeNetworkAcls",
"ec2:DescribeDhcpOptions",
"ec2:DescribeTags",
"ec2:DescribeInstances"],
"Resource":"*"
}
]
}
Further, if you have multiple VPCs that you do not want them to even see, perhaps you should consider creating a sub-account with only the portion of your network that they should have visibility across:
Setup Consolidated Billing
As a first step, log into your AWS account and click the "Sign up for Consolidated Billing" button.
Create a new account
From a non-logged in browser, you will then want to sign up again to AWS again like this:
Give this new account the appropriate name for your client. Note the email address you signed up with.
Link the accounts
In your main account, head back to ConsolidatedBilling and click the Send a Request button. Provide the email address for your new sub-account.
You should receive an email to the email address for your new sub-account. Copy the activation link and paste it into your browser logged in to the sub-account.
Your accounts are now linked!
Create your clients VPC and enable the services that the client requires.
Next, you can create the VPC & services the client requires, and restrict their access via the policy above.
You cannot restrict Describe* calls in the manner you want.
Calls that create resources can be restricted (eg give permission to launch an instance in a particular VPC), but calls that list resources cannot be restricted.
If you require the ability to prevent certain users from listing resources, then you'll either need to build your own front-end that filters the information before presenting it to users, or use multiple AWS accounts since they are fully isolated from each other.