Create an AWS User, Group, and Cross-Account Role for Static Web Management
ACM.229 Setting up cross-account access to deploy websites
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics | Code.
🔒 Related Stories: AWS Security | IAM | Cloud Governance
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTE: I have changed course and built a container that requires MFA for every role which much easier context switching and less complicated roles and policies:
But if you want to see where I started….
This part of this sub-series on creating a static web site in S3.
In my last post I created a new GitHub repository for static web content.
Recall that in this post I created functions to deploy cross-account roles:
Now I’m going to use those functions.
First I want to explain — creating the functions was super complicated. So complicated, in fact, that I forgot what I meant when I wrote that post when re-reading it after two weeks of being away for a family emergency. I also realized I made a mistakes. I’ll continue to try to simplify it. This post is a step in that direction.
Creating an AWS CLI profile to use the default organizations role in an account
I want to deploy a user and group in the Sandbox account. I’m going to use the OrgRoot user credentials to do that and the default AWS Organizations role. More on AWS Organizations here:
The following two lines configure an AWS CLI Profile with temporary credentials for the Sandbox account using the functions I created in the prior post.
change_dir "Organization" $base_path $profile
remoteprofile=$(create_org_admin_role_profile "Sandbox")I created a file called deploy_web_admin_in_sandbox.sh in the app/staticwebsite/ folder created in the prior post and added this code:
Before going any further, I execute the file to test this code.
The change_dir call gave me temp credentials for the OrgRoot user.
Using those permissions, I call the Organizations function that configures an AWS CLI profile with temporary credentials for the default Organizations role in the Sandbox Account.
We now have a temporary session token we can use that is associated default organizations role that can be used to execute commands. Execute commands using the AWS CLI with these credentials such as:
aws s3 ls --profile [your or prefix]-SandboxUse the profile to execute IAM functions in Sandbox account
The name of the profile we created is [your org prefix]-Sandbox. Recall that we were using the profile name IAM when calling IAM functions.
Here’s where I had to make a change. I need to be able to use a different profile.
Look at the change_dir function.
The code:
- Changes to the specified directory.
- Sources the related functions file so you can call the functions.
- Sets the AWS CLI profile to use you specify that has appropriate permissions to run the code in that directory.
I needed to modify some code to use the assigned profile rather than assunming that if you’re in the IAM directory you’re using an “IAM” profile. This has some implications for the naming convention I created which I may address later.
Add code to deploy a new user and group in the SandBox account that will be allowed to assume the cross account role. I’m prefixing the name of the group with Xacct to make it clear that group has permissions to assume a cross account role only.
I had to modify the code that creates a group to accept an account number.
If an account number is provided, it is passed into the policy template, and the account number is used in the ARN for role the users of the group are allowed to assume. I had to fix some of that code in the next post I wrote where I created a test script for cross-account roles:
Execute the file. The CloudFormation stacks are created in the SandBox account.
Verify they got created successfully in the correct account.
Add MFA to the WebAdmin user while you’re in there. Since I allowed console access in my initial run, I added a Yubikey for the console and a Virtual MFA device for the CLI. (See prior posts for why I do that.)
Looks good.
Create the cross-account role in the Sandbox-Web account
Next I created a file called deploy_xacct_webadmin_role.sh.
Call the function that deploys a cross account role. This function, as you would expect, is in the IAM roles functions file if you have been following along.
It takes three parameters:
The code to deploy the cross-account role looks like this:
Before you execute it, we need to add the role policy template for the role in the target account.
Cross-Account Role Policy
I created a policy for web administrators role in the SandBox web account.
Ideally we create roles scoped down to what a user needs, so after running this code we can determine what permissions the user needs based on the actions called as explained in this post:
I’m hoping that I can find a simpler and less costly solution to this problem. Stay tuned for future posts on that topic if I can get to them. For now, I’m keeping the policy simple as I’m trying to demonstrate a concept.
Note: Looking back at this policy, the last statement looks like it allows any action and shoudl be removed. Don’t do that. Refer to the code on GitHub for the latest.
Deploy the cross-account role and verify it exists
Now execute the script and verify the cross account control got created in the Sandbox-Web account. I’ll provide a test script in the next post to help validate cross-account roles using the functions in my codebase.
In Summary we created…
- A group named XacctWebAdmin in the Sandbox account.
- A group policy that allows members of the group to assume a cross-account role in the Sandbox-Web account.
- A user WebAdmin in the XacctWebAdmin group.
- A role in Sandbox-Web that can be assumed by users in the XacctWebAdmin group.
Testing…
Testing is a whole other can of worms. I found that I had some issues trying to run my modified code so I created a test script which I’ll provide in the next post, with any updates to the code.
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