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.
Related
I know a lot of the stuff I already did is wrong.
Here's what happened:
I created a AWS Account and created an Organization.
I added someone else (let's call him Joe) to the orgnization as a root user.
Joe created a bunch of IAM users and those users started creating S3 buckets.
I log back into my root account and I cannot see any S3 buckets
I see nothing running under EC2
And I don't see any IAM users
Basically it seems like we are in completely different world.
I had Joe create an IAM user for me and I was able to login through that account. Through that account, I see everything properly. It is really important that I figure this out because Joe will eventually leave the project and I need to make sure that everything is under the correct AWS root account.
I made sure that the regions are the same. I tried going to my root account and enabling service control policies and attaching FullAWSAccess.
This is how Organizations works.
While you have consolidated billing and can enforce policies across the boundaries, Organizations is about consolidated, high-level management of accounts -- not a consolidated view that all subordinate resources percolate up into.
Accounts are still separate entities, and resources are still owned by and associated with the account that created them -- so unless you want the project to remain in a separate account, you don't want these things to be created in a separate account.
Possibly, the conceptual problem here is that you are considering an AWS account as belonging to a person -- Joe's account -- but that isn't how it's intended. The individual accounts under an organzation are all intended to be your company's accounts -- a division's account, a project's account, etc. AWS accounts "own" users (defined in IAM) -- users don't "own" AWS accounts. The root credentials are the high-privileged credentials of an account, used only administratively for initial bootstrapping and as few other operstions as are necessary -- and are not intended to be used by an individual person beyond that.
See Accessing a Member Account That Has a Master Account Access Role for the way Organizations allows you to switch your console view from account to account without logging out/logging in.
This question may seem noobish, but I am pulling my hair out with our AWS organization. We have 3 separate root accounts connected in a single organization with IAM accounts and policies. We can only see instances from the default root account in the EC2 list (yes I am looking in the correct region). We have shared full account access across all of the others accounts and accepted the invitations. Our billing works perfectly, and funnels from our main root account (and I can see billing of the other separate accounts fine). Even our highest level of admin (literally a grant permission to everything) cannot see instances launched from one of the separate root accounts.
Our goal is our admin group should see EC2 instances from all 3 root accounts in the organization without switching accounts or credentials.
I know this has to be possible, but I have spent at least 2 hours and have not gotten far. Any suggestions on how to achieve this?
There are some terminology issues here. There are no root accounts or main root accounts in AWS Organizations. There is one management AWS account and there are zero or more member AWS accounts.
The term root refers to an AWS Organizations construct within the management account that is the parent container for all of the member accounts in your organization. See AWS Organizations Terminology and Concepts for more.
There are two ways to 'join' a member account to an organization:
an admin in the management account creates a new member account
an admin in the management account invites an existing account to become a member
If you use option #1, administrative control over the member account is automatically provided for you through an auto-created IAM role called OrganizationAccountAccessRole that you can use to grant users in the management account administrator access to the created member account.
If you use option #2, you do not automatically have full administrator control over the member account. If you want the management account to have full administrative control over an invited member account, you must create the OrganizationAccountAccessRole IAM role in the member account and grant permission to the management account to assume the role. To configure this, after the invited account becomes a member, follow the steps in Creating the OrganizationAccountAccessRole in an Invited Member Account.
#jarmod's answer provides a good overview of the terminology. I don't think it addresses your visibility problem.
Your assumptions appears to be that the master account of the organization should be able to directly see all resources of all accounts within the organization in its AWS console or via the API. That's not correct.
The resources in the accounts are generally still separated (allthough some things can be shared, but that's another matter), but you can change into these accounts by assuming a role in the accounts and then you're able to see the resources - this is what #jarmod is describing. After you changed into the accounts, you'll be able to see all resources within that respective account.
To learn more about organizations and their capabilities, here are some helpful links:
Documentation on Managing Access Permissions for Your AWS Organization
Services that can be used in conjunction with organizations
Resources within an AWS Account logically belong to that account and not to its organization.
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 would like to write a policy for a new IAM user so that he can have a full access to AWS Services such as EC2, RDS, Cloud Front, S3, etc. However he should be only able to view (describe) and manage the instances/services that he launches. He can't see other existing/future instances/services created by other users.
This case happens in a company that wants to outsource some projects to an outsourced company. So the new IAM user is for giving access to the outsourced company to setup the staging & production environments in AWS that belongs to the company. How can I achieve this?
Thanks.
Best Regards,
Mark
AFAICT there are no conditions on creator.
One obvious alternative is having a separated dependent and linked account with consolidated billing. You can find some detail in the third scenario of this paper
https://media.amazonwebservices.com/AWS_Setting_Up_Multiuser_Environments_Education.pdf
[...] an administrator creates separate AWS accounts for each user who
needs a new AWS account. These accounts can optionally be linked
together and a single AWS account can be designated as the paying
account using consolidated billing, which provides a single bill for
multiple AWS accounts. The administrator then creates an IAM user in
each AWS account and applies an access control policy to each user.
Users are given access to the IAM user within their AWS account, but
do not have access to the root credentials of the AWS account.
Users can log into the AWS Management Console with their IAM
credentials and then they can launch and access different AWS
services, subject to the access control policies applied to their
account. Users have direct control over the access credentials for
their resources and they can also share these resources with other
users as necessary.
We have multiple AWS accounts (about 15-20), one AWS account per client that we are managing, each account having VPC having dedicated setup of instances. Due to regulatory requirements all accounts needs to be isolated from each other.
What is the best way to manage account credentials for these AWS accounts? Following is what I am thinking
-For any new client
Create a new AWS account
Create AWS IAM roles (admin, developer,
tester) for newly created account using cloudformation
Using master
AWS account, assume roles created in step 2 to access other
accounts.
Is this the right approact to manage multiple accounts?
Thanks in advance.
Facilitating IAM Roles is a very common and (I think) the right approach to manage authentication for multiple accounts indeed, AWS has just recently released resp. updates that greatly help with this, see Cross-Account Access in the AWS Management Console:
Many AWS customers use separate AWS accounts (usually in conjunction with Consolidated Billing) for their development and production resources. This separation allows them to cleanly separate different types of resources and can also provide some security benefits.
Today we are making it easier for you to work productively within a multi-account (or multi-role) AWS environment by making it easy for you to switch roles within the AWS Management Console. You can now sign in to the console as an IAM user or via federated Single Sign-On and then switch the console to manage another account without having to enter (or remember) another user name and password.
Please note that this doesn't just work for the AWS Management Console, but also with the AWS Command Line Interface (AWS CLI), as greatly explored/explained in by Mitch Garnaat in Switching Roles in the AWS Management Console and AWSCLI.
Furthermore, Mitch has followed up with a dedicated new tool 'rolemodel' to help with setting things up pretty much like you outlined, which you might want to evaluate accordingly:
Rolemodel is a command line tool that helps you set up and maintain cross-account IAM roles for the purpose of using them in the new switch role capability of the AWS management console. These same cross-account roles can also be used with the AWSCLI as described here.