I am trying to programatically stop, start and reboot my ec2 instances via the below methods
Ec2AsyncClient.stopInstances(..)
Ec2AsyncClient.startInstances(..)
Ec2AsyncClient.rebootInstances(..)
What is the right way to check if the user has privileges to perform these actions on the given ec2 instances?
Apart from executing the commands another way to check is AWS's IAM Policy SImulator:
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html
Related
We're using the Ansible ec2 module to start instances in an external teams environment, and the module succeeds from the Ansible end but looking at the console it does not register any changes. We are able to successfully stop instances, but not start instances. I've tried to mimic the behavior using the AWSCLI from our AWS bastion host, and that produces the same error where the VM goes into a 'Pending' state, but does not start. We've configured the AWSCLI to use an IAM Profile for authentication vs AWS keys due to constraints from our client, we use this same configuration for our AWS Ansible modules. The profile seems like it has all the necessary permissions based on the AWS documentation. Currently it has the 'AmazonEC2FullAccess' policy as the only policy associated with our role. I would think that would be enough, if we're able to stop instances successfully via those policies, why wouldn't we be able to start? Unless there may be another permission needed? What are we doing incorrectly?
There seems to be plenty of documentation that outlines making a role with its corresponding policies and then attaching that to a new or pre-existing (single) EC2 instance. However, when you have many instances and the task it to attach a role to all of those instances, I can't find or figure a way that avoid doing the process one-by-one.
So, how does one attach an IAM role to multiple already-launched EC2 instances efficiently?
You'd have to do this one by one. It would generally be attached at launch but you can do it afterwards.
Programatically looping would probably be the most efficient
There is no way to bulk-assign roles to EC2 instances.
You can do this programmatically using the CLI or the SDK in your language of choice.
If using the CLI you'll want to use the ec2 associate-iam-instance-profile command. Note that this command still just accepts a single instance identifier at a time so you'll need to iterate through a list of instances and invoke repeatedly.
How to create an AWS policy which can restrict the users to create an instance unless they create tags while they try to launch the instance?
This is not possible using an IAM policy alone. The reason being that all EC2 instances are launched without EC2 tags. Tags are added to the EC2 instance after it has launched.
The AWS Management Console hides this from you, but it's a two-step process.
The best you can do is to stop and/or terminate your EC2 instances after-the-fact if they are missing the tags.
Thanks to recent AWS changes, you can launch an EC2 instance and apply tags, all in a single, atomic operation. You can therefore write IAM polices requiring tags at launch.
More details, and a sample IAM policy, can be found at the AWS blog post announcing the changes.
Is there a way to run ECS containers under certain IAM roles?
Basically if you have a code / server that depends on IAM roles to access AWS resources (like S3 buckets or Dynamo tables), when you run that code / server as a ECS container, what will happen? can you control the roles per container?
Update 2: Roles are now supported on the task level
Update: Lyft has an open source thing called 'metadataproxy' which claims to solve this problem, but its been received with some security issues.
When you launch a container host (the instance that connects to your cluster) this is called the container instance.
This instance will have an IAM role attached to it(in the guides it is ecsInstanceProfile I think is the name).
This instance runs the ecs agent (and subsequently docker). The way this works is when tasks are run, the actual containers make calls to/from AWS services, etc. This is swallowed up my the host (agent) since it is actually controlling the network in/out of the docker containers. This traffic in actuality now is coming from the agent.
So no, you cannot control on a per container basis the IAM role, you would need to do that via the instances (agents) that join the cluster.
Ie.
you join i-aaaaaaa and it has the ECS IAM policy + S3 read only to cluster.
you join i-bbbbbbb and it has the ECS IAM policy + S3 read/write to cluster.
You launch a task 'c' that needs r/w to S3. You'd want to make sure it runs on i-bbbbbb
AWS IAM provides quite granular permissions in regards to the specific types of instances that can be launched by a specific user.
However, I would like to know if it is possible to create a custom policy that would enable me to set an upper limit on the number of EC2 instances that can be created by an individual user (not an account)?
AWS doesn't store which user has launched which machine.
One bypass I recently did was to externalize the logic into a Rundeck job:
the job was calling a python script, in which I controlled the number of instances launched by the user before actually creating a machine or not. The username was taken from the Rundeck user running the script (rundeck was pluged on active directory) and stored in AWS through tags
hope this helps