Looking for suggestions on an AWS use case.
I have a lot of accounts in my AWS.
I am looking to create the same policy in all of my accounts. Now I want to automate it.
1) Can I create any lambda function or cloud formation template or any way to automate the creation of the same policy in all of my accounts even if any new account is created and it needs to add to all existing accounts if it's not there?
2)If possible then how I can get access to lamda function to create policies.
Thanks
If you have multiple AWS accounts, you may want to consider using AWS Organizations and Service Control Policies (SCP). The policies are applied at a root level and affect all accounts under that root.
By using organizations, you can get events when account creation is completed and apply any additional changes to the account that you would like by using a Lambda function that receives a CloudWatch event. The event would contain information about the newly created account.
The two options that provided seem to require a lot of manual administrative overhead, but would be happy to answer your concerns. Creating Lambda function which creates policies is done using the SDK. There is an IAM method called "CreatePolicy" which provides this functionality.
If I'm understanding your needs here (and assuming they're still the same after almost 3 years), you might consider using CloudFormation StackSets instead. They allow you to define common resources, including policies, as a CloudFormation template and have that template deployed to every one of the accounts in your organization.
You'll need to enable trusted access for CloudFormation StackSets in your organization AWS account, which will allow it to deploy the stacks to the rest of your organization's accounts.
To create the stack you'll need to:
Define a CloudFormation template using either CloudFormation directly, or capturing the synthesized stack from an AWS CDK application.
Upload the produced template to a location in S3 that's accessible by your top-level organization account.
Create the StackSet in the CloudFormation console (or the CLI, CDK, etc). You can either deploy the stack to all accounts or filter by specific accounts or organizational units (OUs).
Once created, the stacks will be automatically deployed to the desired accounts, and kept up to date when the stack is updated. This will require you to define significantly less infrastructure.
Related
I'm trying to set up AWS IAM Identity Center (successor to AWS Single Sign-On) for my organisation, and my team has a strong preference for Infrastructure as Code (IaC) wherever practical.
While exploring solutions, I was able to set up an Instance with several Users, Groups and Permission Sets using the Management Console UI. However, now I have come to set up something more long-term, I can't find any way to create an Instance via either CloudFormation or the AWS CLI.
When looking for documentation, I found the CloudFormation reference for AWS SSO, as well as the AWS CLI reference for the sso-admin subcommand. Neither mention any operations that create instances. Neither does the AWS SSO API reference, which leads me to think programmatic access may not be possible.
Is it possible to create an Instance through code rather than the Management Console?
If it is possible, what have I missed?
Is there a way to define a permission/policy/role in AWS which allows to create a CloudFormation Stack using only a specific template (which is updated on S3)?
I've seen AWS Service Roles but I think it's not what I'm looking for. In fact I don't see which is the benefit (in terms of security) of using it. If a user can not create a resource directly, but the same user can create the resource through the CloudFormation where is the benefit?
However, if there were a way to limit the templates which can be use it, it would add a benefit in terms of security, because you could define what resources can be created without need to have specific roles defining permission by permission all the resources of the Stack.
You should take a look at service catalog.
By using this service you can define and hook up the templates that can be used to generate CloudFormation stacks without the need to give team members the permission to create a CloudFormation stack.
Without this there is not a direct solution to restrict access to CloudFormation creation from only specific sources.
For a while, I have used cloudformation and a lambda script to tag EC2 instances, their EBS volumes and network interfaces with the IAM user that created them. Is there a better way to do this automatically with AWS?
AWS does not maintain a relationship between resources and users that create them.
If a user has sufficient permissions to create resources in an account, then any resources created are associated with the AWS Account rather than the user that created them.
One way to discover such a relationship would be to use AWS CloudTrail records, since they reference both the resources involved in API calls and the IAM entity (user, role, etc) that issued the API call.
So, in theory you could:
Create an Amazon CloudWatch Events rule to trigger an AWS Lambda function as new CloudTrail events happen
The AWS Lambda function could look at the event, determine whether it's something of interest (eg a resource was created) and then extract the user information and add it to a tag
It could get a little complex, such as requests coming from IAM Roles associated with Amazon EC2 instances, where it is hard to associate API calls with a "user"
Unfortunately, AWS doesn't support tagging resources automatically with IAM principal tags. You have to craft your own solution as described in the previous answer. However, you can find a couple of projects on Github. I have been maintaining the following project, which applies IAM principal tags and session tags to newly created resources.
https://github.com/erhanux/aws-tags
I want to implement Security in AWS Cloud using IAM like below:
1. Restricting Region(Possible)
2. Restricting Particular Service(EC2/RDS/VPC)(Possible)
3. Restricting IAM user(Disabled other IAM user resources)(Not Sure)
4. Deleting IAM user should delete AWS Resources created by this user.(Not Sure)
I came across Cloud Training site called Qwiklabs where they restrict exactly what I need.
I already tried and done first two restrictions(Region and Services).
Now I'm not sure for remaining 3rd and 4th.
Can anyone suggest me how to implement this scenario?
Ad 3. - Can You elaborate?
In Qwiklabs Your labs are created on separate AWS account - no other users are there.
Ad. 4 - You will have to force all users to use CloudFormation do provision resources or develop a process (Lambda/Step function) triggered by delete user action
4.Deleting IAM user should delete AWS Resources created by the user - You can use AWS Cloudtrail/AWS Lambda for that.
AWS Lambda:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/RunLambdaSchedule.html
You can create a Lambda function which triggers as soon as the user logs in. The first Lambda function should create another Lambda Function with the scheduled events associated.
The second Lambda Function contains the specific user's information, instructions for deleting the resources created by the specific user and the instructions to delete the scheduled event.
With AWS CloudTrail:
By using the below sample command you can get the list of actions performed by the user.
aws cloudtrail lookup-events --lookup-attributes AttributeKey=username,AttributeValue=user#example.com
Once you have that you can delete them.
What are the best practices for CloudFormation stacks that create IAM users? I'm creating an API that will automatically add clients to one of our services, i.e., it uses a CloudFormation template to create buckets, dynamo db entries, IAM user, etc.
You send a POST call to a route with specific parameters in the call, and it will create the client and everything that's needed for them; however, due to security concerns, I'm hesitant to allow a lambda role to have IAM permissions. We take IAM user creation extremely seriously, as this could always have a negative connotation.
Is there a way that I could create a CloudFormation stack, but require an Admin's manual approval to create it? I noticed there isn't a way to "delay" a stack for approval from another entity who has the correct permissions, since, for stacks to be created in the first place, proper policies must be in place for the entity creating it.
So, in summary, send a POST request to a URL that creates a stack needing Admin approval with proper permissions to activate the creation.
I'm starting to believe this isn't possible, so what are some recommendations?
We have thought about some other methods:
API call uploads the generated CloudFormation template to an s3, then admins manually create the stack with object url
Modify the CloudFormation template to remove the IAM section, and have Admins create that portion manually
Either way, it kinda takes away from the "automation" aspect.
Any thoughts?
I would suggest to use AWS Step Functions to create a state machine (a codified process) around the approval mechanism. The POST request would then trigger a new Step Function execution with the specific CFN template. I imagine you would need to build a simple frontend to list all the pending Step Function executions (i.e. pending approvals).
An alternative solution could be built on top of CodePipeline. A pipeline execution can have a manual approval action and it can be configured in a way that it would creating the stack by itself.
If you are open to additional tools, you can trigger the cloudformation stack via a Jenkins job and allow only the admins to trigger that job.