I created two IAM groups, I call them general and lambda-user.
In general:
Policy: IAMUserChangePassword
In lambda-user, I added policies:
AWSLambdaFullAccess
AmazonS3FullAccess
AmazonAPIGatewayAdministrator
AWSCloudFormationFullAccess
I thought when I added a user to both groups, he should have all 5 rights above.
Then, the user tried to use cli to perform serverless deploy that requires CloudFormation, but he failed. The console said he did not have CloudFormation right.
Until I removed him from general, he could perform serverless deploy again.
It seems that the rights in different groups are not adding together, but a group may override another group.
Actually, is my concept of group + group correct?
Related
I want to make an inline policy (i.e, one that exists only in the context of an IAM permission group) a managed one (i.e, one that exists globally). Is that possible? If so, how? (I would prefer AWS GUI solutions and not CLI ones)
It is not possible to convert an inline policy to a managed policy.
What you can do is:
Go to IAM - Groups
Choose the group whose policy you want
Go to Permissions tab
Select inline policy
Open it in JSON Viewer and copy the whole JSON
Go to Policies
Click on Create a Policy button and follow the steps. On the first page, switch from Visual editor to JSON and paste your policy
I believe you are looking for a "Customer managed policy", see more at
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies
You can create standalone policies that you administer in your own AWS account, which we refer to as customer managed policies. You can then attach the policies to multiple principal entities in your AWS account. When you attach a policy to a principal entity, you give the entity the permissions that are defined in the policy.
There is also a section specifically for Converting an inline policy to a managed policy
We are using AWS cloud and terraform with ansible to deploy our current infrastructure.
The code is yml files where we can put whatever works m, but to my concern we cannot apply some group policies to a user role. is this possible or could it be that the console does not show the policies applied from a group to a role.
assigned in our usual modus operandi but i believe it does not work while the functionality may be provided by the usage of extra permissions like expressly specified iam/bucket access policies.
user-test: #this line declares role
assume_arn:
- arn:aws:iam::anonymised:user/test
- arn:aws:iam::anonymised:user/me
groups:
- tf-dev1-group
- tf-dev2-group
- tf-dev3-group
policies:
- athena-fulladmin-policy
- support_access
no error messages just lack of result
I am following these instructions in order to send our EKS cluster logs to CloudWatch:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs.html
Since it wasn't working I ran the suggested to command to tail the logs for one of the fluentd pods:
kubectl logs fluentd-cloudwatch-fc7vx -n amazon-cloudwatch
I am seeing this error:
error_class=Aws::CloudWatchLogs::Errors::AccessDeniedException
error="User:
arn:aws:sts::913xxxxx71:assumed-role/eksctl-prod-nodegroup-standard-wo-NodeInstanceRole-1ESBFXHSI966X/i-0937e3xxxx07ea6
is not authorized to perform: logs:DescribeLogGroups on resource:
arn:aws:logs:us-west-2:913617820371:log-group::log-stream:"
I have a role that has the right permissions, but how can I give the role to the arn:aws:sts::913xxxxx71:assumed-role/eksctl-prod-nodegroup-standard-wo-NodeInstanceRole-1ESBFXHSI966X/i-0937e3xxxx07ea6 user?
You need to perform step to attach the CloudWatchAgentServerPolicy policy to cluster worker node role documented here: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-prerequisites.html
To do this, you need to assume the role. This can be done a few different ways:
You can setup an AWS profile and use that to execute commands as a different role.
You can use a tool like awsudo
One caveat is the the role you are assuming must have a trust relationship setup so that is permits others to assume it. There is an example of this trust relationship setup in the link for (1) above.
That being said, you probably shouldn't be doing any of this for your use case.
If your other role is in a state where it needs to be updated to allow assumption, it is going to be much easier and more secure for you to just update the eksctl-prod-nodegroup-standard-wo-NodeInstanceRole-1ESBFXHSI966X role directly with the permissions you need.
Ideally you can associate the role with the same policy that is attached to the other role with the desired permissions.
I have an IAM group called "devops" to which I want to apply a policy that will grant members of that group full access to EC2 instances tagged "Class=devops", and no access to any other EC2 instances. I found this great knowledge center article by Amazon which put me on the right path: https://aws.amazon.com/premiumsupport/knowledge-center/iam-ec2-resource-tags/.
The problem as I see it stems from the "Note" about halfway down that page:
"Full control" extends to all actions within the EC2 namespace with the exception of those Amazon EC2 API actions that currently do not support resource-level permissions. For more information, see Unsupported Resource-Level Permissions in the Amazon EC2 API Reference.
If you follow the link in the note to the list of unsupported resource-level permissions, you'll find that it's dozens of items long. You'll also find this statement:
All Amazon EC2 actions can be used in an IAM policy to either grant or deny users permission to use that action. However, not all Amazon EC2 actions support resource-level permissions, which enable you to specify the resources on which an action can be performed. The following Amazon EC2 API actions currently do not support resource-level permissions; therefore, to use these actions in an IAM policy, you must grant users permission to use all resources for the action by using a * wildcard for the Resource element in your statement.
In order to grant "allow" permissions to all of these.
If I wanted to grant permissions in this policy to all of those actions which don't support resource-level permissions, my policy would be hundreds of lines long! Is there a better and more concise way to do this?
There is one simple shortcut. A lot of the actions start with the same word such as "Describe". You can cover this list with a wildcard. Example, "Action" : "ec2:Describe*".
Just be careful with actions that will then override your other policy sections that DENY actions for specific resources.
Can someone explain to me the difference between an AWS Policy and an AWS Managed Policy in the context of Cloud Formation?
More specifically, I'm trying to define an auto scaling template where:
Each instance in an auto scale configuration is assigned an IAM Instance Role that has a policy.
The same policy is applied to the user when they try and access these instances.
I'm trying to keep duplication to a minimum and it seems like I may be able to achieve it via a Policy linked to a role, and group of users. The role can then be associated with EC2 Instance via instance profile and users can be added to the groups which in turn are assigned the policy.
Why and under what circumstances would one use a ManagedPolicy?
Thank you for your assistance.
EDIT: It seems like Role requires a policy document irrespective. So even having a separate policy won't really help? Or am I missing something?
AWS::IAM::Role only requires a trust policy. The Policy/Managed Policy can be defined separately.
The difference between AWS::IAM::ManagedPolicy and AWS::IAM::Policy is that AWS::IAM::ManagedPolicy does not require you to assign a Group, Role or User when defining it. AWS::IAM::Policy does. In your use case, you're probably fine using AWS::IAM::Policy.
If I may add, testing Policy creation using CDK v2.12.0, groups, users or roles are not required. iam.ManagedPolicy creates a policy you can share, iam.Policy is created as an inline policy.
new iam.Policy(this, 'testPolicy2', {
statements: policyDocs,
//groups: [s3UserGroup],
policyName: 'testPolicy2'
})
new iam.ManagedPolicy(this, 'testPolicy3', {
statements: policyDocs,
//groups: [s3UserGroup],
managedPolicyName: 'testPolicy3'
})