How to set Access Permission to Cloud Formation Template? - amazon-web-services

Is it possible to set access permission to cloud formation template using IAM policies . If yes how to set the access policies ?

If you go to IAM and search for "cloudformation" in the Policies section you will see a read-only policy called, "AWSCloudFormationReadOnlyAccess". You can of course make you own custom policies but this is where you can restrict the use of CloudFormation.
For the actual templates you can use policies or a role to an S3 bucket that contains the policy template.
Using a combination of the two methods above you can get very granular on how CF and templates are used.

Related

What is the benefit of using `aws_secretsmanager_secret_policy` for creating/managing policy for AWS Secrets manager?

In Terraform aws provider, we can use the below to attach a Resource based policy to the secrets manager.
Create a aws_iam_policy_document Data resource and attach the same to the secrets manger
Create policy using aws_secretsmanager_secret_policy for a secrets manager.
I remember the older versions of the provider for e.g 2.7 did not had aws_secretsmanager_secret_policy and we had to use the data resource to attach policy to the secrets manager. Now the latest version supports both.
What is the benefit of using the aws_secretsmanager_secret_policy over aws_iam_policy_document and under what conditions we can choose one over the other ?
I think your actual question is about setting the policy attribute on the aws_secretsmanager_secret resource, versus creating the policy as a separate aws_secretsmanager_secret_policy resource.
The main reason you would use aws_secretsmanager_secret_policy instead of setting it directly on the secret resource, is if the secret was created in different Terraform code, or perhaps completely outside of Terraform. For example if you wanted to create a Terraform template to look up all your AWS secrets, and set a policy on all of them.
You can use aws_iam_policy_document with either of these. aws_iam_policy_document is just a way to define IAM policies in Terraform code instead of embedded raw JSON strings.
aws_secretsmanager_secret_policy is to create a resource-based policy, whereas aws_iam_policy_document is for identity-based policy. There is a number of differences between them as explained in Identity-based policies and resource-based policies.
The most common scenario where you would use a resource-based policy is for cross-account access to your secret.

How to use cloudformation to create an IAM user/role

I want to create an access key in IAM-User, but I don't have permission to do that, so I want to use cloudformation to create an IAM user/role which I have permission, can anyone shows me a template for that? I couldn't find a correct one, Thanks
I don't have permission to do that
If you don't have permissions to create IAM users/roles you can't create them with CloudFormation either as it uses your permissions, which you lack, to create resources.
The only way would be if you were given a role which can be assumed by CloudFormation to create IAM entities, instead of using your permissions. But this is unlikely. You can ask your AWS admins if they can create/give you such a role for CloudFormation.

AWS cli/boto3- Is it possible to know if a role or policy has permissions over a resource?

I would like to know if I can check if a policy or role can see, list, or edit a resource.
Can be any type of resource, S3 bucket, Secrets Manager, EC2 instance, etc.
I will try to do this through boto3 as well.
You can Test IAM policies with the IAM policy simulator - AWS Identity and Access Management. This allows you to specify a policy and a resource (including conditions) and test whether the API call would be permitted.
If you wish to do this via boto3, you can use simulate_custom_policy():
Simulate how a set of IAM policies and optionally a resource-based policy works with a list of API operations and AWS resources to determine the policies' effective permissions. The policies are provided as strings.
The simulation does not perform the API operations; it only checks the authorization to determine if the simulated policies allow or deny the operations.
If you want to simulate existing policies that are attached to an IAM user, group, or role, use simulate_principal_policy() instead.

Can I use existing AWS IAM role to create S3 bucket via Cloudformation template?

I want to create a S3 Bucket via CloudFormation template. I found there is a way to do it for EC2 instance on this link.
Do we have a way to create S3 bucket using existing IAM role via cloudformation?
It looks like what you're looking for is a service role. From AWS:
A service role is an AWS Identity and Access Management (IAM) role that allows AWS CloudFormation to make calls to resources in a stack on your behalf. You can specify an IAM role that allows AWS CloudFormation to create, update, or delete your stack resources. By default, AWS CloudFormation uses a temporary session that it generates from your user credentials for stack operations. If you specify a service role, AWS CloudFormation uses the role's credentials.
For more information, you might want to take a look at this, specifically the permission part to find out how to use an existing IAM role for creating a Cloudformation stack.
By the way: Unfortunately the link that you've provided doesn't seem to be accessible anymore.
When deploying infrastructure using creating Cloudformation template, you can have 2 ways to do it:
Cloudformation can deploy resources using the permissions of the current user who deploys the CF template. This is the default way
Secondly (Optional), you can choose an existing role that can be attached to the CF template. Cloudformation service will use the permissions of that attached role to deploy all the required services. Given that the attached role has permissions to S3, you can create an S3 bucket as can be seen in the attached screenshot

How do ECR repository policies differ from IAM policies?

How do ECR policies differ from IAM policies?
The language around the ECR policies seem to indicate it is similar to the S3 bucket policy.
Does it allow you to grant access not using IAM?
If I wanted to grant another account access to registry can I use an ECR policy or do I still need a cross account role?
The language around the ECR policies seem to indicate it is similar to the S3 bucket policy.
Yep, they are. Both ECR repository policies and S3 bucket policies control permissions of specific resources rather than permissions of principals (identities). In the case of ECR, it lets you define permissions for a specific repository.
Does it allow you to grant access not using IAM?
Sort of. You need both an IAM policy and a repository policy to express some kinds of permissions. For example, an IAM policy on a user might have permissions like ecr:* in order to allow the user to make API calls to ECR and then a repository policy might grant control over a particular repository.
If I wanted to grant another account access to registry can I use an ECR policy or do I still need a cross account role?
This is one of the primary use-cases of repository policies. A user in account A might have permission to make ECR API calls with ecr:* in the IAM policy. A repository in account B could then grant cross-account access to account A, at which point the account A user does not need to assume a cross-account role in order to access the repository.
According the documentation, you can allow cross-account access to your ECR with just the repo policy:
For Principal, choose the scope of users to apply the policy statement to.
You can apply the statement to all authenticated AWS users by selecting the Everybody check box.
You can apply the statement to all users under specific AWS accounts by listing those account numbers (for example, 111122223333) in the AWS account number(s) field.
You can apply the statement to roles or users under your AWS account by checking the roles or users under the All IAM entities list and choosing >> Add to move them to the Selected IAM entities list.
So you don't need to setup cross-account role assumption, but I imagine you would have to grant the appropriate permissions to the users/groups/roles in the remote account to allow them to talk out to your ECR.