I am relatively new on AWS IAM policies and currently I am trying to create a policy under the AWS console so then I can copy it on to my Terraform file (since I keep getting "MalformedPolicyDocument" errors).
I am trying to allow permissions for kinesis to work with lambda and also travis to work with lambda. What I see in some places is that I should add lambda:UploadFunction as an Action for travis to work (e. g. https://github.com/travis-ci/docs-travis-ci-com/pull/755/files) However when I am on the console Policy Generator there isn't such option under AWS Service: AWS Lambda.
I will try to add it anyway and see what happens but I just would like a clarification whether I am confusing things or if the console doesn't have all lambda action options available.
Related
I am using AWS application composer to create my serverless stack.
Specifically on Lambdas, i need to add additional IAM policies that have been included in my Lambda code logic. For example, some of the AWS service IAM policies access. I know I can add the additional access after deployment at the AWS IAM page, however this is not ideal especially we might forget or it would be difficult to pass the setup code and templates to other teams.
Any insights? Thanks.
I have searched the reference or documentation but could not find any workaround.
If you are referring to policies attached to Lambda service role, you can add it.
Since Application Composer uses SAM AWS::Serverless::Function templating, you should be able to add it under the Policies field, it is in the Application Composer console under Details as well (you need to scroll down to the bottom)
https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html#sam-function-policies
As stated in the documentation -
This property accepts a single string or a list of strings, and can be the name of AWS managed policies or AWS SAM policy templates, or inline IAM policy documents formatted in YAML.
You can try to add that in. For example:
I need to create a CloudFormation SAM template that creates multiple resources. I also need to integrate GitHub Actions so code gets auto deployed on push. The problem is this requires that I give GitHub a lot of IAM permissions to do the necessary work. Note that I'm using an Open ID identity provider for GitHub as opposed to api keys.
How do I find out which IAM permissions are needed at minimum so I don't give GitHub more than what is necessary? Is there an AWS tool that can parse the deployment template and tell me which permissions are needed for both deployments and rollbacks?
No, there's no such tool. You can however look at the Cloudtrail logs to see which actions are being invoked by CloudFormation, and based on that you could put together the list of required policies.
Alternatively, you could replicate what the CloudFormation template is doing by using the AWS CLI. That way, you could use iamlive to generate the IAM policies required for those CLI commands.
Consider I want to run some AWS CLI command, e.g. aws s3 sync dist/ "s3://${DEPLOY_BUCKET_NAME}" --delete.
How do I know what specific permissions (actions) do I need to grant in order for this command to work correctly? I want to adhere to the least privileged principle.
Just to clarify my question. I know where to find a list of all actions for S3 or other service and I know how to write a policy. The question is how do I know what specific actions do I need to grant for some CLI command?
Because, each command will use different actions and the arguments of the command also play a role here.
Almost every command used in the AWS CLI map one-to-one to IAM Actions.
However, the aws s3 commands such as sync are higher-level functions that call multiple commands.
For sync, I would imagine you would need:
ListBucket
CopyObject
GetObjectACL
PutObjectACL
If that still doesn't help, then you can use AWS CloudTrail to look at the underlying API calls that the AWS CLI made to your account. The CloudTrail records will show each API call and whether it succeeded or failed.
There's no definitive mapping to API actions from high-level awscli commands (like aws s3 sync) or from AWS console actions that I'm aware of.
One thing that you might consider is to enable CloudTrail, then temporarily enable all actions on all resources in an IAM policy, then run a test of aws s3 sync, and then review CloudTrail for what API actions were invoked on which resources. Not ideal, but it might give you something to start with.
You can use Athena to query CloudTrail Logs. It might seem daunting to set up at first, but it's actually quite easy. Then you can issue simple SQL queries such as:
SELECT eventtime, eventname, resources FROM trail20191021 ORDER BY eventtime DESC;
If you want to know for S3 specifically, that is documented in the S3 Developer Guide:
Specifying Permissions in a Policy
Specifying Conditions in a Policy
Specifying Resources in a Policy
In general, you can get what you need for any AWS resource from Actions, Resources, and Condition Keys for AWS Services
And you may find the AWS Policy Generator useful
I've been told to restrict my Cloudformation to only the commands it needs. With a role. To create the role I can spend months going through my template to decide that launching an EC2 instance actually involves 10 different IAM items (like creating tags, network interfaces, volumes, etc..) and figure out all the ARNs in question and so on for all my resources. (Because these resources aren't created yet, I'm going to need a lot of * for this role to be useful next time.)
OR, is there a tool to do that for me? I imagine supplying my template and the tool going away and making the bulk of the role. Maybe a few bits to change where the template does things based on parameters maybe.
OR, if I create the stack with Cloudtrail turned on, is there a tool to convert from cloudtrail logs to a policy document?
OR any other way to avoid months of work?
Your requirements to restrict your CloudFormation's execution role, to only the commands it needs is definitely best practice, and in the CloudFormation console, when you're launching a template there is an option for "Permissions" that says:
Choose an IAM role to explicitly define how CloudFormation can create, modify, or delete resources in the stack. If you don't choose a role, CloudFormation uses permissions based on your user credentials.
What this is saying is that when deploying your template CloudFormation can either use your users permissions to deploy the services defined in your template or, in accordance with best practice and the principal of least privilege, CloudFormation can assume a role that has been designed and defined with permissions that are specific to this specific template. This is best practice because we want to be certain of the services and resources that are being used and executed.
There are a few ways you can achieve your goal of determining what permissions CloudFormation needs to deploy your template. In your case I imagine you have many resources, and because of this it seems like a mammoth task that will take months to figure out, but the reality is that it will take just a few hours. I'll suggest two ways you could accomplish this... Lets begin:
CLI
Create a new role from my CLI that has no permissions. Be sure to create the trust relationship to allow CloudFormation to assume the role.
Create a new blank policy document and attach that policy to the role you just created.
Add an ALLOW iam:PutRolePolicy for that new policy I just created.
Assume the role new from the CLI, so that you're using that role going forward
Create a bash script that is going to repeatedly attempt to deploy the CloudFormation template until it successfully deploys it. Assuming the template is formatted correctly, each time the script try's to deploy the template it's going to receive a permissions error because the role that was assumed in step 2 doesn't have the correct permissions. The error is going to look something like:
ClientError: An error occurred (AccessDeniedException) when calling the xxxxxxxxxxxx operation: User: arn:aws:sts::[ACCOUNT-NUMBER]:assumed-role/[my-Role-Name]/[Logged In Username] is not authorized to perform: iam:PassRole on resource: xxxxxxxxxxxxx
In the example above, our template needed to perform iam:PassRole but the role assumed doesn't have permission to do that, hence the error. To solve this have the script parse the iam:PassRole from the error (ie the permission it needs), and add then add an iam:PassRole inline policy to the role that was created in step 2 above via the aws iam put-role-policy command (syntax and full requirements here).
Once the policy is attached to the IAM role, the script should then loop back and try to deploy the template again. It should to keep doing this until the template successfully deploys, or until it receives some other error which is unrelated and it stops executing completely. When it deploys successfully, you'll now have a role that has the exact permissions needed, via inline policies, to deploy the template.
NOTE 1: depending on your account settings and/or the number of resources in your template, you could easily find yourself hitting permissions boundaries or exceeding policy size limits, these are outside the scope of this question but you may find yourself needing to address those issues.
NOTE 2: to be sure, this is a potentially dangerous technique and this sort of script should only be run in a dev environment to prevent unwanted outcomes. If you unwittingly had a destructive operation in your CloudFormation template and ran it in a production account, this sort of script could cause a disaster incident; it would be prudent to only run a script like this in a dev so you'll be able to see all the permissions that are created, identify if you have any unexpected or unwanted operations/permissions, and then you can craft an appropriate role and policy for deployments in your production account with the necessary permissions.
CloudTrail with Console based deployment
A less advanced method would be to use CloudTail in a non-production account to audit the permissions being used by CloudFormation and craft a policy from that (effectively the second option in your question). I'm not aware of any off-the-shelf scripts to parse CloudTrail logs and create policy documents, but doing it manually is not difficult and scripting it can also be done. Nonethless, if you do go with this option, at this stage, I'd suggest sticking with using the console as you'll quickly be able to see what you need.
Login to a non-production account with a user that has admin permissions
Head over to CloudFormation and deploy the template using the logged in users permissions (ie admin)
Once deployment is complete, head over to CloudTrail to find all the permissions that were used by that user during the deployment; filter the list by User name, and then from the events you'll be able to see what permissions were used.
Craft a policy that has the permissions that were used by CloudFormation
Take that policy and add it to the deployment role that CloudFormation will use in the production account
Depending on your bash scripting skills, both of these options should take about the same amount of time; a few hours, maybe even a day, definitely not months.
Good luck!
My code is running on an EC2 machine. I use some AWS services inside the code, so I'd like to fail on start-up if those services are unavailable.
For example, I need to be able to write a file to an S3 bucket. This happens after my code's been running for several minutes, so it's painful to discover that the IAM role wasn't configured correctly only after a 5 minute delay.
Is there a way to figure out if I have PutObject permission on a specific S3 bucket+prefix? I don't want to write dummy data to figure it out.
You can programmatically test permissions by the SimulatePrincipalPolicy API
Simulate how a set of IAM policies attached to an IAM entity works with a list of API actions and AWS resources to determine the policies' effective permissions.
Check out the blog post below that introduces the API. From that post:
AWS Identity and Access Management (IAM) has added two new APIs that enable you to automate validation and auditing of permissions for your IAM users, groups, and roles. Using these two APIs, you can call the IAM policy simulator using the AWS CLI or any of the AWS SDKs. Use the new iam:SimulatePrincipalPolicy API to programmatically test your existing IAM policies, which allows you to verify that your policies have the intended effect and to identify which specific statement in a policy grants or denies access to a particular resource or action.
Source:
Introducing New APIs to Help Test Your Access Control Policies
Have you tried the AWS IAM Policy Simulator. You can use it interactively, but it also has some API capabilities that you may be able to use to accomplish what you want.
http://docs.aws.amazon.com/IAM/latest/APIReference/API_SimulateCustomPolicy.html
Option 1: Upload an actual file when you app starts to see if it succeeds.
Option 2: Use dry runs.
Many AWS commands allow for "dry runs". This would let you execute your command at the start without actually doing anything.
The AWS CLI for S3 appears to support dry runs using the --dryrun option:
http://docs.aws.amazon.com/cli/latest/reference/s3/cp.html
The Amazon EC2 docs for "Dry Run" says the following:
Checks whether you have the required permissions for the action, without actually making the request. If you have the required permissions, the request returns DryRunOperation; otherwise, it returns UnauthorizedOperation.
Reference: http://docs.aws.amazon.com/AWSEC2/latest/APIReference/CommonParameters.html