I want to share a potential option to deploy a bastion/forensic workstation with a micro-pipeline quickly for Incident Response as Code in an AWS account and or organization.
Single Sign-On (SSO) needs to exist to handle authentication and authorization for this method to work.
I prefer to use Cloud9 as my forensic workstation these days. It comes pre-installed with most of the necessary developer tools to stand up new infrastructure to process an investigation.
Choose no-ingress EC2 instance for the environment (access via Systems Manager). No ingress security group rules or ssh key pairs exist on the Cloud9 host this way. The disadvantage is that not all EC2 and System Manager (SSM) traffic remains in the VPC unless Endpoints get established.
Free-tier is not always the best long-term solution as T2 instances do not support VPC Traffic Mirroring if packets are ever required. Select any Cloud9 instance type except T2 that meets your process, memory, and budget requirements.
Typically I have been using Amazon Linux 2 as it has AWS CLI and SSM Agents installed by default.
For the budget-conscious, Cloud9 has an auto-hibernate feature to shut off EC2 when not in use, so you only pay for allocated Elastic Block Storage (EBS) costs when not running. Unfortunately, this volume will not have disk encryption enabled at launch.
Cloud9 requires Internet or VPC Endpoint access to the EC2 and SSM APIs to provide access. The disadvantage is a public IP is assigned even if the host gets launched in a private subnet.
I tend to enable termination protection as a fallback safety net if I forget to commit my code.
The default installation only has 10 GB of storage allocated, not leaving enough room for all the necessary dependencies. I would recommend a minimum of 20 GB for your disk storage starting point.
These commands will finish expanding the disk space available for the operating system.
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 20G 0 disk └─xvda1 202:1 0 10G 0 part / $ sudo growpart /dev/xvda 1 $ sudo reboot now
The volume usually does not have the space available to patch until after the disk modification is complete.
$ sudo yum update -y
Check to make sure you are on the most current AWS Cloud Development Kit (CDK).
$ cdk version
Newer versions of CDK on Cloud9 may allow a simple update path.
$ npm install -g aws-cdk
If the command returns any errors, the .npm and .nvm hidden directories will need deleting before a full install of CDK.
$ sudo rm -R ~/.npm ~/.nvm $ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.0/install.sh | bash $ nvm install stable $ npm install -g typescript $ npm install -g aws-cdk
Install AWS CLIv2 to be able to authenticate against SSO from the command line.
$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" $ unzip awscliv2.zip $ sudo ./aws/install $ aws --version aws-cli/2.2.9 Python/3.8.8 Linux/4.14.232-176.381.amzn2.x86_64 exe/x86_64.amzn.2 prompt/off
Install YAWSSO to synchronize AWS CLIv2 SSO login sessions to legacy CLIv1 credentials for CDK bootstrapping.
$ pip3 install yawsso
Install AQUEDUCT to automate Cloud Development Kit (CDK) bootstrapping into an AWS Organization using Single Sign-On (SSO).
$ pip3 install aqueduct-utility
Disable the AWS managed temporary credentials to use the SSO login.
Configure the AWS CLIv2 to use SSO access for Cloud9 in the current account to obtain command-line permissions. If you need extra help, here is a link to some excellent documentation.
$ aws configure sso
First, we need to set up the utility to use SSO for CDK bootstrapping.
$ aqueduct SSO Start URL [ ]: https://portal.awsapps.com/start SSO Region [ ]: us-east-2 SSO Role [AWSAdministratorAccess]: CLI Region [ ]: us-east-2 CLI Output [json]: CDK Qualifier [ ]: 4n6ir CDK Trust [ ]: 111111111111 add -h or --help for usage help
Next, we need to add accounts, regions, and tags necessary to bootstrap the accounts and regions.
$ aqueduct --addacct Account Name [ ]: Pipeline Account Number [ ]: 111111111111 $ aqueduct --addreg Region [ ]: us-east-2 $ aqueduct --addtag tag i.e. key=value: 4n6ir=4n6ir
Then, we can synchronize the SSO ~/.aws/config and legacy CLI ~/.aws/credentials files.
$ aqueduct --ssosetup $ yawsso
Now, we can bootstrap a micro-pipeline for performaing Incident Response as Code.
$ aqueduct --bootstrap CDK_NEW_BOOTSTRAP set, using new-style bootstrapping ⏳ Bootstrapping environment aws://111111111111/us-east-2... Trusted accounts: 111111111111 Execution policies: arn:aws:iam::aws:policy/AdministratorAccess cdk-bootstrap-4n6ir-111111111111-us-east-2: creating CloudFormation changeset... [██████████████████████████████████████████████████████████] (11/11) ✅ Environment aws://111111111111/us-east-2 bootstrapped.