I have the following scenario:
We are build an infrastructure on AWS with infrastructure as code (IAC) on multiple accounts.
I have account A and account B in the beginning, and I want to create the infrastructure in both using CloudFormation and Terraform. When account A is created, I want to allow a role in account B to have access to a S3 bucket, that is created in account A. The role in account B is not yet created, however, I do know, what the name is eventually going to be.
My question: Can I grant access to non-existing resources between both accounts, if I do know how they are going to be named eventually?
OR: Do I have to create the resources before I can grant the access?
Stack Sets would allow you to run manage stacks in multiple accounts and regions with CloudFormation. CloudFormation is pretty smart about dependencies, but you can explicitly use the DependsOn attribute to have resources wait for the dependent resource to be ready, like the IAM Role for cross-account access in this case.
Related
I have an AWS account used by different people.
I want to give access to IAM Users in the IAM User Group Developer to only the resources they created. They should be able to create any resources and read and write all the resources they created.
So, when you logged as IAM User A part of IAM User Group Developer, you can read and edit all the resources IAM User A has created since the beginning. Also, you will be able to create any other resources.
I prefer to avoid using AWS Organisations. Moreover, there are resources shared across the account. There is already an Admin role and a ReadOnly role for these resources.
One solution would be to ask developers to use their AWS Accounts and permit them to access the main one with IAM Roles. However, I would like your help with a solution using only one AWS Account.
I want to create a role for a Lambda function that allows it to create/update/delete any resource, as long as that resource was also created by it. For example, it should be able to create an SQS queue and do anything with it, but it should not have access to any other SQS queues from that AWS account.
Can this be achieved using IAM policies?
I've tried to use resourceTag and requestTag conditions for this, allowing the role to create or modify a resource only if is tagged with a specific value. Unfortunately, a lot of AWS services do not support authorization based on tags.
Are there other options for achieving this?
You could create IAM policies that only allow a user to create, update, delete resources that have a particular naming scheme. For example, you could set the policy's resource arn to have "/username*". The user would only be able to create resources that start with their username and effect those resources. They wouldn't be able to effect resources created that started with another users name and vice-versa.
It is very hard to do in practice. You would have to combine the tags that you already mentioned, along with permission boundaries.
I think the best way to achieve this is to give you application its own dedicated AWS account, so that you can scope its permissions to that account, and it doesn't have the ability to impact other applications.
I am having some trouble doing code deploy with my AWS Educate account. Initially, when I was setting things up I was following this article.
https://hackernoon.com/deploy-to-ec2-with-aws-codedeploy-from-bitbucket-pipelines-4f403e96d50c?fbclid=IwAR3rezVMGpuQxTJ3AneOeTL2oMHjCKbQB5C5ouTLhJQ5gRp3JeL4GK0f53o
In it is talks about setting up an IAM service account. The problem is that AWS Educate allows you to create the accounts but it won't generate keys. In order for me to deploy my Spring Boot (and VueJS) apps to my s3 buckets and ec2s from my bitbucket repo, I need a key and secret key and CodeDeploy Group.
Fine I was able to use my Click the Account Details button on the labs.vocareum page and get my keys, however when I am attempting to set up a Code Deploy Group it asks for a service role and I am unsure where to get this?
Why is the service role necessary?
The service role is used by the CodeDeploy service in order to perform actions outside CodeDeploy (i.e. on another service such as S3).
AWS has a special approach of integrating services. Basically, you have to give each service you are using explicit permission to use another service (even if the access stays in the bounds of the same account). There is no inherent permission given to the CodeDeploy service to change things in S3. In fact, CodeDeploy is not even allowed to read files from S3 without explicitly allowing it.
Here is the official explanation from the docs [1]:
In AWS, service roles are used to grant permissions to an AWS service so it can access AWS resources. The policies that you attach to the service role determine which AWS resources the service can access and what it can do with those resources.
What you are actually doing according to the hackernoon article
you need a user account with programmatic access to your aws account
the user account needs to have a policy attached which grants permission to upload files into S3 and trigger a CodeDeploy deployment --> you provide the access key and secret access key of this user to Bitbucket so it can upload the stuff into S3 and trigger a deployment on bahalf of your user identity
Unrelated to steps 1 and 2: Create a role in AWS IAM [2] which will be used by both services (NOT Bitbucket): CodeDeploy and EC2. Strictly speaking, the author of the hackernoon article is merging two steps into one here: You are creating one role which is used by both services (as specified by the two different principals in the trust relationship: ec2.amazonaws.com and codedeploy.us-west-2.amazonaws.com). Usually this is not how IAM policies should be configured because it violates the principle of granting least privilege [4] as the EC2 instances receives permissions from the AWSCodeDeployRole policy which it probably does not need as far as I see. But that is just a philosophical note here. All the steps mentioned in the hackernoon article should technically work.
So, what you actually do is:
granting CodeDeploy permission to perform various actions inside your account, such as viewing which EC2 instances you have started etc. (this is specified inside the policy AWSCodeDeployRole [3])
granting EC2 permission to read the revision which was uploaded to S3 (this is specified inside the policy AmazonS3FullAccess)
To get back to your question...
However when I am attempting to set up a Code Deploy Group it asks for a service role and I am unsure where to get this?
You need to create the service role by yourself inside the IAM service (see [2]). I do not know if this is supported by AWS Educate, but I guess it should be. After creating the service role, you MUST assign it to the CodeDeploy Group (that is the point where you are stuck right now). Moreover, you must assign that same service role to you EC2 instance profile.
References
[1] https://docs.aws.amazon.com/codedeploy/latest/userguide/getting-started-create-service-role.html
[2] https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html#roles-creatingrole-service-console
[3] https://github.com/SummitRoute/aws_managed_policies/blob/master/policies/AWSCodeDeployRole
[4] https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege
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
We have large number of IAM users ( in hundreds, can increase more then 1000 in future ).
All the IAM users have access to create EC2 instances. Simultaneously around 30-40 users will be working and creating EC2 instances.
In AWS Management Console, an IAM user can see all the instances created by other IAM users as well.Is it possible to visibly make him see only those EC2 instances which he created and hide all the other instances created by other IAM users?
I do agree that IAM users can give names and tags to recognise their instances. However i am looking for visibly hiding those resources which he has not created.
If IAM policies allowed specifying a required filter, this would be possible. But you can't specify it, so it's not possible.
What you want is called Organizations - You can give each group their own AWS account, so they can see their own billing, etc.
Reserved Instances can flow from the master account to sub account
Bills flow from the sub accounts to the master account
All your users can remain in the master account, you just give them AssumeRole capabilities to view their account.
You can apply Service Control Policies that prevent sub-accounts from doing things.
You may think management is "easier" with one account - but the opposite is true. Just like you should treat servers as "Cattle not Pets" (i.e. they are disposable), you should think of AWS accounts as disposable. Some organizations give each developer their own AWS account, and only a build server can modify the Staging/Prod accounts via TerraForm or CloudFormation.
What you would typically use for this is resource level permissions. What resources / what you can control varies from API call to API call in AWS. In particular, what you would want is a resource-level permission on the DescribeInstances API call. Unfortunately, AWS does not currently support resource-level permissions on this API Call.