I want the users want to use the private [shared from another account] or owned AMIs only. I've tried searching in the AWS documentation and stckoverflow. Does any one know if this can be done?
Thanks
You cannot restrict permissions for specific users within the specified AWS account. All users in the AWS account that you've specified can use the AMI or snapshot. http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html
I believe you can restrict to certain AMIs by following this document:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policies-for-amazon-ec2.html#ex5
The 2nd example includes a policy that specifies a list of AMIs that can be launched, while the 3rd example show how to restrict to just Amazon AMIs.
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
I'm using PowerShell with AWS SDK along with cross account IAM roles. Does anyone know if there is an API available to get this?
All API calls are account-specific. There, such a script would need to loop through each account and query separately. The script would either need an IAM User credentials for each account, or it could call AssumeRole() if it has permission to access and IAM Role in each account.
Within an account, the script would need to retrieve via DescribeSecurityGroups(), look through the Inbound rules and find any instances of the Elastic IP addresses.
Is there a policy action in IAM that will restrict the visibility of resources in the colnsole to only a tagged set? So for example can i use ec2:Describe with a StringEquals condition for the tag such that a group of users will only ever see the set of EC2 servers their project is using?
Ideally i dont want all users in this VPC to see all servers regardless if they are read only
Its not currently possible:
Note Currently, the Amazon EC2 ec2:Describe* API actions do not
support resource-level permissions, so you cannot control which
individual resources users can view in the console. Therefore, the *
wildcard is necessary in the Resource element of the above statement.
For more information about which ARNs you can use with which Amazon
EC2 API actions, see Supported Resource-Level Permissions for Amazon
EC2 API Actions.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policies-ec2-console.html
On option you have, that might work is to use multiple, independent AWS accounts, so each user can get there own 'sandbox' to play in, but setup consolidate billing so that that aspect of the accounts are all shared by one master account.
I have a scaling group of several EC2 instances.
I have API keys which I would like to distribute to the instances using round-robin.
How can I code the instances to get the credentials once they go live?
Is there an AWS service for that?
It is not AWS credentials which could be solved by defining IAM Roles.
Thanks
Use "user data" option when you start your EC2 instance, You can run the bash script.
I recommend the following step.
1-put your cred or other shared information to S3 or dynamoDB.
2-write script to read and setting this data when your EC2 was starting.
The closest thing AWS has to this is called IAM Roles. A role includes a set of IAM permissions (like an IAM user). When you start a VM, you can set the role of the VM. The VM can then call the AWS API and get temporary credentials that give it access to the services that are defined in the IAM role.
See here for more details:http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html
This does not exactly meet your requirement for round-robin credentials distribution. But it might be a better option. IAM roles are as secure a method of distributing credentials to EC2 instances as you can get.
AWS now provides two services that could be used for that purpose:
The Secrets Manager would seem to be the most fitting, but does cost money from the start.
The Parameter Store is also an option and is free for up to 10k parameters.
I am in the early stages of writing an AWS app for our users that will run our research algorithms using their AWS resources. For example, our code will need to spin up EC2 instances running our 'worker' app, access RDS databases, and create access SQS queues. The AWS Java SDK examples (we are writing this in Java) use a AwsCredentials.properties file to store the Access Key ID and Secret Access Key, which is fine for examples, but obviously not acceptable for our users, who are would be in essence giving us access to all their resources. What is a clean way to go about running our system on their behalf? I discovered AWS Identity and Access Management (IAM) which seems to be for this purpose (I haven't got my head around it yet), esp. Cross-account access between AWS accounts. This post makes it sound straightforward:
Use the amazon IAM service to create a set of keys that only has
permission to perform the tasks that you require for your script.
http://aws.amazon.com/iam/
However, other posts (e.g., Within IAM, can I restrict a group of users to access/launch/terminate only certain EC2 AMIs or instances?) suggest there are limitations to using IAM with EC2 in particular.
Any advice would be really helpful!
The key limitation with regards to RDS and EC2 is that while you can restrict access to certain API actions there are no resource level constraints. For example with an IAM S3 policy you can restrict a user to only being able to perform certain actions on certain buckets. You can write a policy for EC2 that says that user is allowed to stop instances, but not one that says you can only stop certain instances.
Another option is for them to provide you with temporary credentials via the Security Token Service. Another variant on that is to use the new IAM roles service. With this an instance has a set of policies associated with it. You don't need to provide an AwsCredentials.proprties file because the SDK can fetch credentials from the metadata service.
Finally one last option might be consolidated billing. If the reason you are using their AWS resources is just because of the billing, then setup a new account which is billed from their account. The accounts are isolated from each other so you can't for example delete their instances by accident. Equally you can't access their RDS snapshots and things like that (access to an RDS instance via mysql (as opposed to the AWS api) would depend on the instance's security group). You can of course combine this with the previous options - they could provide you with credentials that only allow you to perform certain actions within that isolated account.