We are building a service on top of AWS for our internal org to manage their AWS accounts based on the reference documentation here.
Ref : http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html
Question : Referring to the document, our service is the equivalent of 'ExampleCorp'. Hence, we have to share our AWS account number for assuming roles for our project aws accounts.
Is it a security concern to share our 'AWS account number' ? Can someone use this information (AWS Account Number) for malicious purpose ?
Or,
Should we create a AWS account number per project/user ?
Note :
(The only reference i found in internet related to this is the link below & it claims its ok to share -
https://acloud.guru/forums/aws-certified-solutions-architect-professional/discussion/-KRUT9T6gFZ4Ebyv0hLp/my-aws-account-id-should-it-remain-private).
Thanks
Sharing AWS Account numbers is fairly safe among business partners. There is not much if anything that anyone can do with just the account number. To assume a role, the account number is required, but the authorizing account must also setup a trust relationship for the policy. Just be careful with which permissions to give to the IAM role for the partner.
The comment in the link that you referenced regarding tricking Amazon. They would need to know a lot more information than what was mentioned. Amazon is very smart and very careful in this regard.
You need to think thru why you are granting access to a third party to decide if separate accounts are required. For example, if you are purchasing a security / monitoring service from a third party, they will need to access the instances in your account(s) that have the instances.
Is it a security concern to share our 'AWS account number' ? Can someone use this information (AWS Account Number) for malicious purpose ?
You will have to share your Account id if you need someone to provide you cross account access. That's how to establish a trust relationship. So there should be no security concerns around sharing your account number.
Or,
Should we create a AWS account number per project/user ?
No you don't. Just use one account to link to other projects.
Sharing AWS Account Number As External ID
This is No No! Generate a unique string for external ID for each cross account role you want to assume. Your external id is something that recognizes you assuming that role and which also establishes your trust relationship. If you just use your account numer as external ID and for some reason your IAM user credentials are compromised your linked accounts (with roles) are also potentially compromised. My suggestion would be generate new external ids for each project and possible (specifically for your usecase) generate IAM users per project and assign them policies to assume role for respective account projects only and other AWS services that may be required.
Related
Our AWS account has been hacked due to someone wrongly supplying an Administrator level access key.
We didn't have an Organisation set up, but the attackers created one. They have then created linked accounts within the organisation and created EC2 instances within them.
The problem I have is that I can't see any way to:
Delete the linked accounts (it says I need to add a payment method to the linked account)
View or terminate the EC2 instances on the other accounts
Can someone please tell me if it's possible to use my root login to access the EC2 instances on the linked accounts? This is costing us a lot of money in the last few hours unfortunately. I have a support case with AWS but they have mentioned that it could take 2-3 business days...
I have disabled users via IAM and made keys inactive.
Thank you in advance.
Based on the comments.
Since the OP already contacted the support, the one thing to do was to access the compromised accounts from the master account and disable the instances. The procedure to do it is explained in the AWS docs:
After I use AWS Organizations to create a member account, how do I access that account?
When you create a AWS account in an Organization you set up a roles that the organization account can use to assume access into that account. If you can see what role is used for these accounts use that role and and assume access into it and take down what you need.
To get the concept of it better you can try to create your own account with organization and assume that role.
This should work as long as the hacker haven't done anything to the role.
Here is docs on how to do this:
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html
Let's assume in current AWS organization we have 2 developers accounts. From what I found it is a good practice to create a separate AWS account per environment and give access to these resources.
My question is:
What is the best way to share access to the resources (e.g. EC2, EKS, EFS) for multiple developers? Now I see only these two options:
Create a separate AWS account for each developer and allow to access some resources by applying roles to that developers AWS accounts.
Within a root account of each AWS environment create a IAM user account for each developer and from that point manage permissions by policies and user groups.
Please let me know. I appreciate any type of help! :)
You should setup AWS SSO. Either integrated with your existing identity provider, or using the built in user system.
https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html
This will allow you to create permission sets. Then, you can assign permission sets to users in particular accounts. This will create a role in the account which the users can assume
I am wanting to share a Lambda Layer with someone and by doing so I will give them it's ARN which will contain my AWS accounts 12 digit ID.
Is there any risk associated with this?
I'm assuming you trust the party you're sharing the Lamda ARN with.
The risk of sharing your account ID is limited to what permissions you have granted for services.
The AWS Account Identifiers documentation states that:
The AWS account ID is a 12-digit number, such as 123456789012, that you use to construct Amazon Resource Names (ARNs). When you refer to resources, such as an IAM user or an Glacier vault, the account ID distinguishes your resources from resources in other AWS accounts.
Someone you've shared the account ID with could manipulate ARN's but without permission to access that resource there is no issue.
Bottom line, if you have tight controls that limit external access to resources (in your case the Lambda layer) you should be fine.
While it is generally not recommended to publish your Account ID (eg in StackOverflow questions), it is not terrible if other people know it.
The security of your AWS services is tied to credentials, not the account ID.
Knowing your account ID simply makes it easier for attacks to attempt to probe your account, especially if they know some of the services you are using. For example, they could look for publicly accessible Amazon SQS queues, knowing that they belong to your account.
If you are intentionally working with other people who wish to tie-in to your account, you can certainly share the ARN.
I'm looking for something that can programmatically spin up instances for other AWS users after oauth. Is there something like this that Amazon provides? So they can just login with AWS account and then I can make AWS calls on their behalf.
Is there anything like this out there?
There's no logging in here. You need a cross-account role, supplied by the owner of the other account.
There is nothing like this.
It would have massive security implications.
Note that the primary entity in AWS is not the user, it is the "account." Accounts have users, and those users can only do what the account has authorized them to do.
For one AWS account ("mine") to allow another AWS account ("yours") to perform actions on behalf of my account (technically, not on behalf of "me"), I have to explicitly give you permission to do so, via IAM. One solution is to create a role with the necessary permissions and delegate access to you.
But this is unlikely to be something a well-informed user would permit, since you could easily run up substantial expenses for the user. Allowing such external access would not be a good practice.
There is, however, a way for users to launch your software on EC2 and optionally pay you a license fee billed on your behalf by AWS, through the AWS Marketplace, which is oriented towards a one-click experience for the user.
Background: On Azure (we're in the process of moving from azure to aws), we have everything organized into resources groups. By default no one can do much in the prod subscription(account), but based on the team asking for a provisioned resource, a team member gets stamped as the "owner" of the resource group, which just gives him/her full access to that resource group, and can add/remove other members as they see fit. This allows us to set up a very fine-grained set of access controls where each team ultimately decides whats allowed and not - not based on groups but based on users getting access to resource groups (in which instances and other resources exist).
Now that we're moving to AWS I had hoped to use the SAML integration to provide access (we're running Auth0 in front of AzureAD, but this should be the same for any saml/federated aws setup I think).
My problem is that with SAML AWS doesn't really "see" each individual user - they're not auto-created in IAM at first logon or anything, so the only "security boundary" I have to work with are the groups I send into AWS, which I can assign to IAM roles.
This is a problem, because 1)the user has to select the desired role at login (if member of more than one), and 2)each role setup is a manual task which requires me to configre AzureAD, saml claims in auth0 and finally IAM roles in AWS. The latter is obviously something I can automate, but still.
Here's the core of my problem:
Say that I have 2 EC2 instances in AWS: DB and Web. I have 3 users, AdminPete, DBDave and WebWilson. I'd like to be able to give Pete full access to both instances, while Dave and Wilson gets access to "their own" ec2 instance. As far as I can see, I would have to configure two IAM roles (DB and Web), and require Pete (who has access to both) to choose his role at login. This is a super-simple example, but it doesn't really scale well at all.
I'm curious to hear how you guys are doing access control in aws - my goal is to be able to create a very fine-tuned setup using tags or some other mechanism. The official aws documentation only deals with getting saml configured (which is easy enough), but very little about real-life permissions management.
The core of the problem (imho) is that unlike "regular" iam users, I can't attach an iam policy or a group to a single user when that user is federated - I can only attach the policy to the federated role as a whole.
Any pointers appreciated! At this point I'm considering just not using saml at all for our aws stuff so that we can use fine-grained iam policies to manage permissions in a more flexible manner.