I have been messing around Amazon Web Services(AWS) with one single account for quite a while. I created and removed several EC2 instances, Lamdbda functions, NAT gateways etc.
Through all those, I created too many new roles and now, after settling down the stuff I ended up with a garbage of IAM roles -there are many of them.
To clean up, I want to find the roles that are not attached to any kind of item, resource or user (or idle for a period maybe, etc.) and remove them.
I searched the net but generally there are docs to reduce permissions of a particular role, which's fine but not the thing I want.
Login to AWS Management Console
Select your IAM role
Click the "Access Advisor" tab
The contents of this tab will display the last access time for each of the various services (S3, EC2, etc.)
Delete the role based on the last access time. Active roles should usually show recent access time
To be able to do it programmatically see https://stackoverflow.com/a/46815052/7983309
Related
My developer has created an EC2 instance on AWS and I want to be able to access it via my own dashboard.
What I did is:
As a root user, I created an IAM account for me and him and assigned us both to a group named PowerUsers
I created an Organizational Unit and added his account to it
When he goes to his EC2 dashboard, he sees his created instances. But when I go to my EC2 dashboard, I see nothing. We both selected the correct region.
I hope someone can help us out here, I can't seem to get any wiser from the AWS documentation.
tl;dr there is a difference between visual access and technical access. Technical is possible, via IAM roles and permissions, etc. Visual access is not possible, not in the AWS console from a different account.
Generally you do not see resources from other accounts that you have access to. That is simply not how AWS / IAM or basically any complex permission system works.
Same thing for S3 buckets, you cannot see S3 buckets you have access to in your S3 console, not those that are public to everyone and not those that you have explicitly been granted permission to. You only ever see the buckets that you / your account actually own(s).
The reason for that from a technical perspective is really simple: AWS simply does not know which buckets / EC2 instance you can access. It knows your permissions and if you want to access a specific resource AWS can check if the permissions let you access it but not the other way around.
IAM has permission that can grant permissions based on IP, time of day, VPC, etc. That makes it impossible and not really meaningful to display what you can access now because in 10 second or from a different network it might be that you cannot see it at all.
Let me tell you from personal experience and currently building one myself: If you build a permission system it is built to answer "can I do X" but listing all X is a VERY different story, IAM cannot answer it and I have not come across a permission system that can answer it while at the same time having a complex permission structure AND being efficient. Seems like you cannot have efficiency, complexity and reverse lookup / list at the same time.
Note that you still have access to the resource. E.g. when manipulating the browser URL to directly access the resource you can view it even though you are not logged into the owning account but at that point you are asking "can I do X" (X = "view resource") and that can be easily answered. You only cannot list the resources.
Second note: some of the listed resources you see and that your account owns you still cannot access because there might be an explicit IAM Deny policy for your current role in place that only takes effect when interacting with the resource.
Following are some options;
Better way is to use, Cross-Account Access using switch roles and also refer this
Bit tricky way using Python sign-in script.
I know it might sound like a basic question but I haven't figured out what to do.
We're working on having a testing environment for screening candidates for Cloud Engineer and BigData interviews.
We are looking into creating on demand AWS environments probably using Cloudformation service and test if the user is able to perform specific tasks in the environment like creating s3 buckets, assigning roles, creating security groups etc using boto3.
But once the screening is finished, we want to automatically tear down the entire setup that has been created earlier.
There could be multiple candidates taking the test at same time. We want to create the environments (which might contain ec2 instances, s3 buckets etc which are not visible to other users) and tear down them once the tests are finished.
We thought of creating IAM users for every candidate dynamically using an IAM role and create a stack automatically and delete those users once the test is finished.
However, I think the users will be able to see the resources created by other users which is not what we are expecting.
Is there any other better approach that we can use for creating these environments or labs and deleting them for users? something like ITversity and Qwiklabs.
The logged in user should have access to and view the resources created only for him.
Please suggest.
Query1:
Let's say I have created 10 IAM roles using and one user using each of those roles. Will the user in created from IAM role 1 be able to see the VPCs or EC2 instances or S3 or any other resources created by another user which is created by IAM role 2?
Will the resources be completely isolated from one IAM role to another?
Or does service like AWS Organizations be much helpful in this case?
The Qwiklabs environment works as follows:
A pool of AWS accounts is maintained
When a student starts a lab, one of these accounts is allocated to the lab/student
A CloudFormation template is launched to provision initial resources
A student login (either via IAM User or Federated Login) is provisioned and is assigned a limited set of permissions
At the conclusion of the lab, the student login is removed, a "reaper" deletes resources in the account and the CloudFormation stack is deleted
The "reaper" is a series of scripts that recursively go through each service in each region and deletes resources that were created during the lab. A similar capability can be obtained with rebuy-de/aws-nuke: Nuke a whole AWS account and delete all its resources.
You could attempt to create such an environment yourself.
I would recommend looking at Scenario 3 in the following AWS document:
Setting Up Multiuser Environments in the AWS Cloud
(for Classroom Training and Research)
It references a "students" environment, however it should suite an interview-candidate testing needs.
The “Separate AWS Account for Each User” scenario with optional consolidated billing provides an excellent
environment for users who need a completely separate account environment, such as researchers or graduate students.
It is similar to the “Limited User Access to AWS Management Console” scenario, except that each IAM user is created in
a separate AWS account, eliminating the risk of users affecting each other’s services.
As an example, consider a research lab with 10 graduate students. The administrator creates one paying AWS account,
10 linked student AWS accounts, and 1 restricted IAM user per linked account. The administrator provisions separate
AWS accounts for each user and links the accounts to the paying AWS account. Within each account, the administrator
creates an IAM user and applies access control policies. Users receive access to an IAM user within their AWS account.
They can log into the AWS Management Console to launch and access different AWS services, subject to the access
control policy applied to their account. Students don’t see resources provisioned by other students.
One key advantage of this scenario is the ability for a student to continue using the account after the completion of the
course. For example, if students use AWS resources as part of a startup course, they can continue to use what they have
built on AWS after the semester is over.
https://d1.awsstatic.com/whitepapers/aws-setting-up-multiuser-environments-education.pdf
However, I think the users will be able to see the resources created by other users which is not what we are expecting.
AWS resources are visible to their owners and to those, with whom they are shared by the owner.
New IAM users should not see any AWS resources at all.
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.
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.