People who code: we want your input. Take the Survey

Hot answers tagged

11

The purpose of the AssumeRolePolicyDocument is to contain the trust relationship policy that grants an entity permission to assume the role. In your example it's granting the Lambda service the ability to assume References https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html https://docs.aws.amazon.com/cli/latest/...


10

Amazon's IAM roles generally grant a role access to a particular ARN (Amazon Resource Name). Amazon notes on their pages that for S3 a resource ...can be a bucket-name or a bucket-name/object-key. They also provide a helpful example for doing just this which appears as follows: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", ...


7

For anyone who is scratching their head at the naming convention: AssumeRolePolicyDocument (in CloudFormation yaml) = Trust Relationships (in AWS Console web GUI) Policies (in CloudFormation yaml) = Permissions (in AWS Console web GUI)


7

The purpose of assume role policy document is to grants an IAM entity permission to assume a role. It is also known as a "role trust policy". In other words, for given permissions you set, it allow users from certain AWS account to assume this role and access that account. It is recommended that you update the role trust policy to restrict access to only ...


6

Well, from a security point of view, it's never bad to give people less information. But, as long as you have sensible security policies in AWS, there is no reason that an arn has to be considered secret. For example, if you know the arn of the role I use to access s3 from my EC2 instances, you can't do anything with that information unless I give you ...


5

https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html lists the schema for (I believe) all of the ARNs that Amazon supports. Text in italic red indicates where you should substitute in your own value, rather than the literal string, and there are examples in each section to help figure this out. Be warned that IAM is less usefully ...


5

From Granting a User Permissions to Pass a Role to an AWS Service: To pass a role (and its permissions) to an AWS service, a user must have permissions to pass the role to the service. This helps administrators ensure that only approved users can configure a service with a role that grants permissions. To allow a user to pass a role to an AWS ...


4

This is actually pretty well described in the docs. Before you create worker nodes, you must create an IAM role with the following IAM policies: AmazonEKSWorkerNodePolicy AmazonEKS_CNI_Policy AmazonEC2ContainerRegistryReadOnly Also you need to make sure that this role could be assumed by EKS. { "Version": "2012-10-17", "...


4

Access Key is that AKIA... one. What you need is a Secret Key - that can't be recovered after the initial setup. Since you have never used this particular access key (it says "Last used: N/A") it's safe to Make inactive and then Delete and then create a new one through Create access key button above the form. Hope that helps :)


4

S3 Life cycle policy will remain and working as it is. When you use the AWS Management Console to delete an IAM user, IAM automatically deletes the following information for user: The user Any group memberships. The user is removed from any IAM groups. That the user was a member of Any password associated with the user Any access keys belonging to the ...


4

The policy will still exist. The documentation lists what is deleted when a user is deleted, any resources that the user has created will persist.


3

Supposing the scenario with two accounts A & B the explanatory steps should be: In account A, I created a role (e.g RoleForB) to trust account B, and attach to the before created role a IAM policy to allow it to perform some read operations in account A. e.g ReadOnlyAccess In account B, I created a role (e.g AssumeRoleInA) and attach a policy to allow ...


2

Attach below policy to that user: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:ListAllMyBuckets" ], "Resource": "arn:aws:s3:::*" }, { "Effect": "Allow",...


2

Sure, if the EC2 role allows STS::AssumeRole you can assume a role in the other account and get temporary credentials to do whatever you need to do in the other account. See for example here: Cross Account Access with AWS-CLI


2

Attach a policy to the source bucket Get the AWS account ID number of the destination account. From the source account, attach a policy to the source bucket that allows the destination account to get objects, similar to the following: Important: For the value of Principal, be sure to enter the AWS account ID number of the destination account. { "...


2

Call Lambda's UpdateEventSourceMapping API with the {"Enabled":true/false} request body. If, for some reason, you want your own API for this, you can create one in API Gateway as described below. Before you begin, you need the UUID of the event source mapping you wish to enable/disable. Use the AWS CLI to get this (it isn’t shown on the UI): aws ...


2

Yes It does more than just creating a service account. It does three things: It Creates an IAM role. It attaches the desired iam-policy (--attach-policy-arn <POLICY_ARN>) to the created IAM role. It creates a new kubernetes service account annotated with the arn of the created IAM role. Now It's easy to declare the above steps using kubernetes and ...


2

Don't nest moustaches. Once you're in a Jinja context, you should reference variables by name without any further delimiters. Using standard attribute access syntax can be a lot easier to read than the attr() filter (and actually works for this situation, which attr() doesn't): - name: Debug jinja2 ansible.builtin.debug: msg: "{{ ...


1

I have not tried it but I think if you change your deny to a list of elements it will work. { "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::<redacted>:root" }, "Action": "sts:AssumeRole", "Condition": { "StringNotLike": { "sts:...


1

Create an IAM role in prod with all the permissions you'd like the devs to have. When you want devs to have prod access, add the sts:AssumeRole permission to their IAM group. When it's time to revoke access, remove the sts:AssumeRole permission. More details in my blog article here.


1

I found what i needed to allow or the eqivalent StringNotEquals to deny useing the tag aws:ResourceTag "Condition": { "StringEquals": { "aws:ResourceTag/Key_-1": "Value_-1" } }


1

IAM Role for Fargate has two policies: The first one describes which service can assume the role and its permissions. In this case it will be the ecs-tasks.amazonaws.com service (= Fargate) that can call sts:AssumeRole to get all the permissions from this Role. When Fargate assumes the role it gets the permissions specified within, these are the SSM, KMS ...


1

You can get all used User accounts with Cloudtrail, it would then be a text processing exercise to find the unused ones.


1

create a service which authorizes against SSO and the provides temporary credentials via AWS STS Service. That way you don't have to store anything anywhere and once the user loses access to SSO they will also lose access to AWS. You need a role with the access to your dev environment and the developers will assume that role.


1

You can download or read the Secret Key only when you set it up for the first time. If you lost the Secret Key / didn't manage to save it and is not being used anywhere, it is better to Delete and create a new one. Don't forget to copy the Secret Key before you move to any other screen this time :)


1

I believe you would be using multiple modules to create various resources(EC2,ELB, Etc) in AWS using Terraform. You can create a custom module having output value of each variable you want to configure per your requirement like aws-region, etc. Then source(import) this custom module into your resource module and use its values using $. custom_module ...


1

If you want to create your own IAM policy, you can use the visual editor present in IAM. Using visual editor, you can construct a new policy from scratch using the very intuitive GUI. Goto IAM, then policies, then use visual editor.


1

You can have two approaches: Assume the role that has access to the AWS bucket. Assume this role in every account (don't forget to set up trust relationship). This is your approach. I think the issue might be some objects (state files) were created in a different way. Other culprit can be an account-specific KMS key that is used to create the objects. Don't ...


1

I think it's much clearer when considering the user that creates a role isn't necessarily the one attaching it for use somewhere: AssumeRolePolicyDocument is a restriction placed by the user that creates the role - e.g. possibly an admin. It prevents other users from attaching it to any AWS service / user they like. Also, it tells nothing about where it's ...


1

Alternatively, is there another way I could allow an IAM user to launch an instance in line with a template, while preventing them from making changes (such as choosing a super-expensive instance type)? I've encountered this problem last year and have circulated up to our AWS account's architect, who contacted their IAM division. AWS's response is that ...


Only top voted, non community-wiki answers of a minimum length are eligible