I want to make an account to external consultant to help us with AWS, but I want to allow him to only see certain EC2 instances instead of all.
I've read AWS documents/blogs about AMI and policies setting. I'm aware "describe" action can not have resource level permissions.
Is there any workaround to this? or we really need to let external consultant see all the instances' information?
this is currently not possible as many EC2 actions do not support resource-level permissions. check the answer to this question on their knowledge center site, and here I am quoting.
This is not currently possible for all API actions within EC2, but it is for some. Many essential EC2 actions do not support resource-level permissions or conditions, and isolating IAM users or groups of users’ access to EC2 resources by any criteria other than AWS region does not fit most use cases
Related
I would like to run a batch job on-prem and access AWS resources in our account.
I think the recommendation is to create an IAM user, which will be a machine user. Since I don't have a way to assign a role to the on-prem machine, or federate with AWS identity, I'll create an access key and install it on the on-prem machine. What's the best way to link my machine user to a policy?
I can create an IAM policy which allows the required actions (reading AWS SSM Parameters).
But, how should I link the machine user to the policy? I'm setting up these users/policies with Pulumi. Some options I'm aware of:
I can create a role, but then I think the machine user would have to assume the role. (My understanding is that roles do not have immediate "membership", it's just that users have the ability to assume roles. Or, AWS infrastructure can be set up with a role, like an EC2 or an EKS cluster can act as a role. In the future I do plan to move this job's execution to AWS infrastructure, but for now that's not an option.) Is assuming a role easy, for example a aws sts CLI call that I could put in my batch job's startup script before calling the main binary?
Or I could just attach the policy directly to the machine user. Generally that's not recommended from what I've read: you should have a layer between users and policies so when users change what they're doing you have indirection. But in this case maybe that's fine.
Or finally I could create a user group, attach the policy to the group, and add the machine user as a member of the group. Is that layer of indirection useful / an appropriate use of groups, especially if I'm already managing these policies with IaC? Most documentation recommends roles for the user-to-policy indirection, so I'm hesitant to use groups that way. However, that seems to be the expected approach for human users (glad for feedback on that too).
"Is it better to use AWS IAM User Group, or IAM Role for users to assume?" says a group would help manage permissions for multiple users (but so does Pulumi and I only have 1 or 2 machine users); and a role would help separate access rights from long-lived credentials but it seems like rotating the machine user's access key would have that benefit too without the extra assume-role step.
I work as a contractor for a large enterprise company and I was assigned to a new project recently for which we need to request resources on AWS. For our project we will need access to EC2 and RDS.
I am not very familiar with AWS, so my question is: will it be possible to get access to AWS Web Console for our team with limited services (access only to EC2 and RDS in our case)? How much work is needed to provide such access (to set up IAM etc)?
I am a bit concerned that I will not get access to AWS Web Console, because I was asked if I needed a sudo user for a VM. It was frustrating for me to hear such question, because I will need several VMs rather than one.
By default, IAM Users have no access to services. In such a situation, they can access the AWS management console, but there will be many error messages about not having access to information, nor the ability to perform actions.
Once an IAM User is granted the necessary permissions, the console will start working better for them. However, it an be difficult to determine exactly which permissions they require to fully use the console. For example, to use the EC2 console, the user would require ec2:DescribeInstances, which allows them to view details about all EC2 instances. This might not be desirable in your situation, since they might not want these users to see such a list.
Then comes the ability to perform actions on services, such as launching an EC2 instance. This requires the ec2:RunInstances permission, but also other related permissions to gain access to security groups, roles and networking configuration.
Bottom line: Yes, you will be able to access the AWS management console. However, your ability to view or do things will be limited by the permissions you are provided.
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.
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 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.