I am trying to create a tool to easily create and destroy AWS accounts in my AWS organization (or at least remove them from the organisation if they can not be deleted). Those accounts are going to be sandbox with a small budget and destroyed after a couple of weeks.
I found that Terraform has a specific resource for that called aws_organizations_account.
However, this is mentioned that deleting this Terraform resource will only remove an AWS account from an organization. Terraform will not close the account. The member account must be prepared to be a standalone account beforehand. See the AWS Organizations documentation for more information.
I deployed an aws_organizations_account resource using terraform, it worked. But when I am trying to delete that resource, I am a warning issue that The member account must be configured with a valid payment method, such as a credit card
main.tf
resource "aws_organizations_account" "account" {
name = "sandbox1"
email = "first.last+sandbox1#company.com"
role_name = "myOrganizationRole"
}
Is there any way to get around this issue?
Is there any way to get around this issue?
Sadly, no. When you remove AWS Account from AWS org, it becomes normal standalone account. You need custom solution for removing accounts from AWS Org, which would require you to full-fill all its prerequisites listed here. One of them is having valid contact and payment info associated with the account to be removed.
You can delete the account (its different them removing from AWS org), but this can't be done from AWS Org. Account has too be closed from inside, using root.
We have a very similar situation (sandbox accounts). We still need to be able to deprovision accounts as team members off-board. To account for consolidated billing and the inability to remove or delete member accounts, we are allowing those to remain while we remove IAM users and login profiles. The way we do this is to use one set of data for users and another for accounts. This leaves a different type of state that doesn’t fail during user removal.
I wrote about and shared our terraform setup: https://cromwellhaus.com/leaving-aws-subaccounts-behind
You could be more nuanced with the accounts side of you wanted.
Deleting an account is now available with the close account api. This functionality is enabled on terraform via the close_on_deletion flag.
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 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 want to separate out AWS resources for a multi-tenanted SaaS into separate accounts under an AWS Organization.
I have multiple OUs, split by function, e.g. logs, audit, compute. I will have SCPs associated with each OU.
Each tenant will have an account under each OU, which means as I add new tenants, each account will inherit the respective SCP to that OU.
To enable the developers to build out the platform and to be able to debug the running system, I want to use a hub-and-spoke type approach to access control using a federated IdP, similar to that described here: https://segment.com/blog/secure-access-to-100-aws-accounts/.
Specifically, I will have an identity account that will be bound to Okta. Users will authenticate into this account and then use sts:assume-role to escalate to roles in other accounts. Note that I want a separate identity account and not have users authenticate to the master account in the organization (thus within the organization, we have master and identity accounts, plus the OUs each with their respective accounts).
In order to programmatically create a new tenant, I need to create the tenant's accounts and place them in the correct OU, and therefore this needs to be done in the master account. I can do this by creating a role within the master account and having developers assume that role from the identity account.
How do I create roles in the new accounts that developers can assume from the identity account? Member accounts have a role called OrganizationAccountAccessRole automatically created (see here for details), but that is set to only be accessible from the master account and it enables access to everything in that account. How can I enable a developer within the identity account to programmatically create new accounts and the roles within them without granting such all-powerful permissions (they should have no more permissions to perform this task than necessary). I don't think I can assume a role in the master account from the identity account and then further assume a role in a third account?
EDIT: I am really only interested in answers that address the steps/configuration needed to achieve the solution I describe.
Cloudformation StackSets addresses this problem.
Basically, the steps are:
Set up roles in the child accounts that have permissions to deploy resource with a trust relationship to the role of the parent account (which you're deploying from)
Create a StackSet in parent account and deploy a Cloudformation template into it to selected accounts or Organizational Units (OU) or whole organization
StackSets supports AWS Organizations so you can select OU's instead of selecting individual accounts.
I would put forward that an elegant solution is to use the AWS Service Catalog product which allows you to create and manage catalogs of services that are approved for use in your AWS environment. As a matter of fact, the setup described in this AWS blog post can be customized to achieve what you want. It provides an example for creating an Account Builder product that when launched by your end users, uses an AWS Lambda script to:
Provision an AWS member account
Assume the Organizational Role for the account
Use a CloudFormation template to customize the account (in your case, to create the additional IAM roles)
You can customize it further to even delete the Organizational Role account when it's done.
Source code for the Lambda function along with the CloudFormation templates is provided that you can tweak to produce the exact behavior you are looking for.
Hope this helps.
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.