re:Boot ~ Creating an AWS Account
ACM.142 Complications led me to create a new AWS account from scratch for my next experiment
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.
🔒 Related Stories: Cloud Governance | IAM | AWS Security
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yesterday I wrote about creating a policy to delegate access to a new, dedicated governance account.
In the posts before that I set up the account manually in Control Tower due the complexity of automating things with Control Tower. It just doesn’t work the way I’m writing my code. Control Tower requires extraneous things I don’t want to add to my code to test and demonstrate what I’m trying to convey in these governance blog posts. It may work fine if you’re not trying to do the things I’m doing.
In the last post, I was going to automate the creation of the Delegated Administrator account I created but I hit some glitches long the way with the way I was trying to do it. I finally just decided to start over in a new account. Here’s how I created the new account — with some tips for people who are new to AWS.
Starting with a brand-new AWS Account
When you have a brand new account, all you have is the AWS root user. That’s the user that uses the email and password that you used to create your AWS account. Where do you start? You want to automate everything but you want to have control of that code in your source controls system so you can maintain it, check the integrity, and modify it as needed.
That pretty much rules out Control Tower as far as I can tell. Control Tower creates a bunch of things with code you don’t control (easily). You don’t have the option to put the code in your own source control system and deploy and modify from there.
It’s an interesting approach because on the one hand, AWS cloud just give you functionality in the form of a service that you have no control over at all. But instead they create this Control Tower service that deploys things in your account on your behalf. I’m glad they don’t do the former based on the implementation of the latter. It add numerous SCPs to your account which are hard to read and have overlapping code, as I explain below.
I decided that what I really need to do is create an account from scratch instead of trying to simulate that from an account that already has Control Tower and SSO deployed in it. It’s creating complications. I can’t exactly deploy the governance model I want to deploy without spending a lot of time reading Control Tower documentation and the documentation of all the different things it uses like Service Catalog. I’m trying to keep this simple (as possible).
Where do you start when you create a new AWS account?
Let’s say you have a brand new account and you want to set up the governance OU and account I mentioned earlier. You might use Control Tower, but then you’re going to get this whole complex account structure you may or may not need, along with the parts I like, in concept — default policies and alerts. Along with that comes some other challenges that make it hard to modify and maintain via code.
Creation of a new OU and account is not simple. Nor is registering the OU and account with Control Tower. I figured out how to create an account integrated with Control Tower in a Lambda function, but not the AWS CLI or CloudFormation, if that is even possible. I haven’t looked recently and at this point I want to try something different.
I found the whole service catalog integration to be somewhat confusing. I could spend a lot of time figuring it all out, but I am guessing I can just demonstrate what I want to do much more quickly by writing my own code. You would have to set up a lot of infrastructure to get to the point of a Lambda function when starting with a brand new account (to do it right).
Again, I want to keep it simple. Creating a new organization and a new account is simple. I went ahead and created a new AWS account for this purpose and will demonstrate the organizational structure creation in future posts. In this blog post, you can verify that you’ve take basic security hygiene steps when you set up your AWS account.
Create a new AWS account
I’m presuming you can go to aws.amazon.com (or whatever link is applicable for your region or use case), click on the link to create a new account and follow the steps.
The only caveat here is to think about where and how you want to be billed for your organization. On the CEO’s credit card or some other way? Refer to AWS billing for that. Different options exist that may be suitable for different types of organizations and use cases.
Also, you don’t want the email to be one person’s personal email. Set up an email alias and send emails to multiple people. That way if one person leaves the company or you need to shut down that person’s email for some reason, other people can still get messages.
Root Credentials
Store the user name and password securely. We’re not going to use them much. Make sure the owner of the company has access to them — not a random contractor. I recently heard about a company that had their entire company set up in an account where the root credentials and MFA belonged to a contractor and they were all sharing it. The company is now involved in a lawsuit and the person performing digital forensics has no way to tell who did what. The logs will just show an admin login — but the company has no way to prove who it actually was that logged in if they all shared the same login and credentials.
DON’T DO THAT!
Every user gets their own credentials and MFA device. The owner of the company or top executives should have the root credentials and never login with them once you set up your initial users except in case of emergency.
OK so now that you have a new AWS account, log in.
Navigate to the AWS IAM dashboard. Search for IAM and click on it.
Notice the two bright red warnings (at the moment).
The first one is telling you that you should add MFA to your root user.
The second one does not apply to a new account so I’m not sure why it’s there. When you click on it, it says no policies are affected. This warning should be at the point where someone tries to create a policy with a deprecated option, but anyway you can ignore the second one for now, as long as you read the documentation and don’t copy random source code related to billing policies and add them to your account.
Click Add MFA next to the first warning.
Add an MFA device.
Options:
- You can use an app on your phone (Virtual MFA). I mentioned that I was going to use that for my automation accounts.
- For users logging into the console via the web a hardware security key is preferable.
- The last option is single purpose device that generates TOTP codes for AWS. Instead of getting the code from your phone that has a lot of other things running on it, you can use a single purpose device.
Which MFA option should you use?
I prefer a hardware security key for logging into websites (like the AWS console) on a local laptop or device.
I wrote about why I use virtual MFA for automation here:
And issues about AWS SSO CLI access here:
The last option is interesting for automation as well, because you have an out-of-band single purpose code generator device or card for AWS. I had the card option a long time ago but it kept getting out of sync so I stopped using it.
Safenet that was part of Gemalto where I got the card back them is now is part of Thales. I think Thales was a stronger option for hardware key management devices (HSMs) to begin with, so perhaps these devices have improved since that time. I met people from both companies (and worked with some) who work elsewhere now so I don’t really know anything about the current state of either solution. I would have to do a new assessment.
The token device with a push button to get a code perhaps stays in sync better than the card. It might be interesting to revisit these devices for automation purposes at some point. But I’d probably stick with a Yubikey for the root account to avoid any syncing issues, especially when you don’t use the account for long periods of time. That’s when my card or token tended to be out of sync when I got back around to using it.
One of the main concerns I would have with the last option is the security of the infrastructure that makes this all work. Why? You can also read about the RSA SecureId breach here and speak to your vendors about it:
That story above and a related experience is why I have my opinions on the security of various devices and solutions. But it’s something I really can’t talk about, and it probably is a moot point now. Just make sure you do a proper security assessment on your vendors if you are going to use these devices or any third-party authentication service.
Activate MFA twice
Add a second MFA device as a backup. Put each device in a safe place. That way if one device gets lost or stolen you can use the second one. Also, you might choose to use different types of devices for different purposes.
Documentation
Again — make sure these MFA devices are stored in a secure place, like a safe, when you’re not using them. Document the account number and any other pertinent information about the account, who has access to the root credentials, the devices, and and procedure for when they will be used, with whose approval, and how you will access credentials, monitor their use, and restore them to a safe place when you’re done. Like a safe. Where people can’t find the information sitting on a printer or in someone’s desk drawer in shared office space.
Create an Account Alias
One other thing you’ll want to do right is create an account alias. This is a short name that can be used in place of your account number in the sign-in url and when users are logging in. Add the alias and URL to your root account documentation.
Note that if you use AWS SSO you’ll end up using a different URL to login (a url that I always for get and find more complicated than simply going to the AWS console and putting in my account alias).
Now what?
Woot! You have an AWS account. You could start making other changes right away, but best practice is to lock away those root account credentials. So we need to create a new user for day to day use and probably multiple with different levels of permissions — even if you only have one user in your account.
Now here’s the conundrum I was facing in the root management account for my organization when trying to automate the delegated administrator access. I was trying to simulate a brand new AWS account and I couldn’t. Here’s the scenario.
Let’s say we create this new account and the AWS root user (the one you just created above) just logged in for the first time. We have not yet granted any other permissions. We want to give access to our governance account to create SCPs before we allow anyone else into the accounts. What does the aws root user have to do in order to programmatically set up the delegated administrator?
Well, they could set up a secondary admin user that has permission to run the initial scripts to establish an organization, create the initial governance OU, IAM and governance accounts, and a governance and an IAM user, role, and group who can then implement the remaining resources.
To avoid confusion, I renamed the user I’ve been calling “ROOT” in my code to IAMROOT. I will update my code accordingly. You can think of this as IAM ROOT or I AM ROOT — whichever you prefer.
Due to complications automating this user I initially created it manually. See an upcoming post for a run-down on those complicatons and how you can create this user in an automated fashion.
I added the user to an IAM Group that has full admin permissions (see my prior posts if not familiar with IAM groups).
This is a really, really bad thing to do in general. This account is super risky. I did this for a temporary test only. I will show you how to do this in a safer way in a couple more posts. I am simulating an initial setup and “in-case-of-emergency” account only and I was going to use this account to create my organizational policy. But I hit some speed bumps.
I want to create an AWS IAM user, not an SSO user so I’m going to sign in from the aws.amazon.com login link. Here’s where you can use that account alias we just created on the IAM dashboard.
Well, guess what. I couldn’t login with an IAM user in my account where Control Tower and SSO were enabled. Perhaps there’s some policy restriction created by AWS Control Tower or SSO.
But there is also nothing in CloudTrail that indicates the failed logins I am generating. Maybe those should be there? #AWSWISHLIST
Side note: I wish that AWS had a separate, consolidated log for account logins throughout an organization, separate from all other activity for any type of login. #AWSWISHLIST.
Perhaps the inability to use IAM users with AWS SSO is documented somewhere but I haven’t looked at the SSO documentation in a while. I probably have this in the slides for the class I wrote but just forgot.
It is at this point where I realize that no matter what I do, I can no longer log into the console using my IAM user. What causes this anyway? Is it an SCP?
Evaluating Service Control Policies Created by AWS Control Tower
Let’s check out the SCPs created by AWS Control Tower to see if it’s blocking AWS IAM.
Well, I mentioned that AWS Control Tower SCPs don’t have descriptions in an earlier post. So I can’t look at the descriptions to see if there is one that sounds like it’s blocking IAM users.
There is reason they don’t have good descriptions. First of all, a single policy has so much different logic in it that it is hard to decipher what the policy is doing. Mind you, I have been programming for around 30 years and I’m pretty decent at reverse-engineering, having a certification in malware reverse-engineering. But I don’t have time to sort this all out.
The other thing I notice is that the policies have a lot of duplicate and overlapping code. In some cases, it appears that the code is the same but simply rearranged. In other cases, the code appears to be the same, but the spacing is different.
I fact, two of the policies are identical:
I tried to glance through to see if different policies are for different account or another kind of variation but a quick scan didn’t produce anything.
Well, this is a completely new rabbit hole.
And not what I intended to be working on in yesterday’s post.
Pause to consider options…
Do Overs
This is the point where I decided to create a new account for future posts. Now that I have a new account we can automate creation of an organization, OU, and new account pretty easily, though it won’t have all the controls we want out of the gate like we get with Control Tower. But we’ll get there by creating our own SCPs and governance.
Why am I doing this? Because there are some things about AWS SSO I just don’t like, personally. I know the AWS Control Tower worked hard on this and I applaud their efforts. This is a very helpful service. Other companies may be fine with these things. But here’s what I’m struggling with it:
- I don’t like the integration with the AWS CLI for the reasons I wrote about here:
- I find the options for programmatic updates to Control Tower cumbersome.
- I spent some time playing around with Service Catalog, which I love in concept, but it took too much time to ever actually use it.
- I don’t really like automation roles that get added to accounts and that are potentially not affected by SCPs — something I need to test out to validate.
- You can’t enforce MFA without using a browser like I’m doing on the command line in my code.
- I don’t see the option for the external ID with SSO and the AWS CLI. I need this for some roles I use frequently. But then AWS SSO is not a good fit at all for that use case — it just doesn’t work really well.
- I don’t see the option to limit the AWS CLI configuration to a specific MFA device using AWS CLI.
- You can’t programmatically control sessions the way I plan to demonstrate with the browser based option.
- I don’t really like CloudFormation stack sets, monolithic code, or repetitive code like I’m seeing in the above policies and the CloudFormation templates used to implement Control Tower. That’s hard to decipher and troubleshoot.
- I might try to integrate with a third-party auth provider and I want to see how it works with and without AWS SSO.
- I’m experimenting and I want things to be simpler and faster.
I wrote about how AWS can fix AWS IAM Identity Center (SSO) here and hope to write more about Control Tower in the future as I have ideas about that too:
For right now I just want to test a few things out. AWS is always improving it’s services so hopefully there will be a solution for the above in new iterations of Control Tower.
As the last bullet says, I am experimenting, and I want to do what I’m doing quickly. I can’t do that in a fully automated manner within the context of Control Tower. It’s probably mostly all possible or could be fixed, just not at the speed I would like.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab