# Lab 3 ## Prep - [x] Gitea set up - [x] MFA set up - [x] Add git ignore - [x] Secrets/Token Management - [x] Consider secret-scanning - [x] Added git-leaks on pre-commit hook - [x] Create & Connect to a Git repository - [x] https://code.wizards.cafe - [x] Modify and make a second commit ![image of terminal](./assets/prep-console.png) - [x] Test to see if gitea actions works - [x] Have an existing s3 bucket ## Resources - [x] [Capital One Data Breach](./assets/Capital%20One%20Data%20Breach%20—%202019.%20Introduction%20_%20by%20Tanner%20Jones%20_%20Nerd%20For%20Tech%20_%20Medium.pdf) - [x] [Grant IAM User Access to Only One S3 Bucket](./assets/Grant%20IAM%20User%20Access%20to%20Only%20One%20S3%20Bucket%20_%20Medium.pdf) - [ ] [IAM Bucket Policies](./assets/From%20IAM%20to%20Bucket%20Policies_%20A%20Comprehensive%20Guide%20to%20S3%20Access%20Control%20with%20Console,%20CLI,%20and%20Terraform%20_%20by%20Mohasina%20Clt%20_%20Medium.pdf) - [ ] [Dumping S3 Buckets!](https://www.youtube.com/watch?v=ITSZ8743MUk) ## Lab ### Tasks - [x] **4.1. Create a Custom IAM Policy** ![trust relationships](./assets/trust-relationships.jpg) - [x] **4.2 Create an IAM Role for EC2** ![permissions](./assets/permissions.jpg) - [x] **4.3. Attach the Role to your EC2 Instance ** - [x] **4.4 Verify is3 access from the EC2 Instance** * HTTPS outbound was not set up * I did not check outbound rules (even when the lab explicitly called this out) because it mentioned lab 2, so my assumption was that it had already been set up (it was not). So I had to go back and fix the missing outbound connection. ![screenshot of listing s3 contents](./assets/s3-access-screenshot.jpg) ### Stretch Goals - [x] **Deep Dive into Bucket Policies** - [x] **1. Create a bucket policy** that blocks all public access but allows your IAM role - Implmented using: [guide](https://aws.amazon.com/blogs/security/how-to-restrict-amazon-s3-bucket-access-to-a-specific-iam-role/) ![restrict to role](./assets/restrict-to-role.png) - [x] **2. Experiment** with requiring MFA or VPC conditions. - [x] MFA conditions * MFA did not work out of the box after setting it in the s3 bucket policy. The ways I found you can configure MFA: * [stackoverflow](https://stackoverflow.com/questions/34795780/how-to-use-mfa-with-aws-cli) * [official guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html) * [x] via cli roles - I set up a new set of role-trust relationships. * Update s3 Role: * Update action: sts:assumerole * Update principle (Since you cannot not target groups, I tried setting it first for my user, and then to the root account for scalability) * Add condition (MFA bool must be true) * Commands referenced: I set up a script that looks like this ```bash MFA_TOKEN=$1 if [ -z "$1" ]; then echo "Error: Run with MFA token!" exit 1 fi if [ -z $BW_AWS_ACCOUNT_SECRET_ID ]; then echo "env var BW_AWS_ACCOUNT_SECRET_ID must be set!" exit 1 fi AWS_SECRETS=$(bw get item $BW_AWS_ACCOUNT_SECRET_ID) export AWS_ACCESS_KEY_ID=$(echo "$AWS_SECRETS" | jq -r '.fields[0].value') export AWS_SECRET_ACCESS_KEY=$(echo "$AWS_SECRETS" | jq '.fields[1].value' | tr -d '"') SESSION_OUTPUT=$(aws sts assume-role --role-arn $S3_ROLE --role-session-name $SESSION_TYPE --serial-number $MFA_IDENTIFIER --token-code $MFA_TOKEN) #echo $SESSION_OUTPUT export AWS_SESSION_TOKEN=$(echo "$SESSION_OUTPUT" | jq '.Credentials.SessionToken' | tr -d '"') export AWS_ACCESS_KEY_ID=$(echo "$SESSION_OUTPUT" | jq '.Credentials.AccessKeyId' | tr -d '"') export AWS_SECRET_ACCESS_KEY=$(echo "$SESSION_OUTPUT" | jq '.Credentials.SecretAccessKey' | tr -d '"') #echo $AWS_SESSION_TOKEN #echo $AWS_ACCESS_KEY_ID #echo $AWS_SECRET_ACCESS_KEY aws s3 ls s3://witch-lab-3 ``` * configuration via ~/.aws/credentials * 1Password CLI with AWS Plugin * I use bitwarden, which also has an AWS Plugin * I've seen a lot more recommendations (TBH it's more like 2 vs 0) for 1password for password credential setup. Wonder why? - [x] **3. Host a static site** - [x] Enable a static website hosting (`index.html`) - [x] Configure route 53 alias or CNAME for `resume.` to the bucket endpoint. - [x] Deploy CloudFront with ACM certificate for HTTPS * see: [resume](https://resume.wizards.cafe) - [x] **b. Pre-signed URLs** (see: presigned url screenshot) `aws s3 presign s3:///resume.pdf --expires-in 3600` * Cloudflare Edge Certificate -> Cloudfront -> S3 Bucket * In this step, I disabled "static website hosting" on the s3 bucket * This was actually maddening to set up. For reasons I can't understand even after Google Searching and ChatGPTing, my s3 bucket is under us-east-2 and Cloudfront kept redirecting me to the us-east-1 for some reason. I don't like switching up regions under AWS because this way it's easy to forget what region you created a specific service in because they're hidden depending on what region is active at the moment. ![presigned url](./assets/create-presigned-url.jpg) - [x] Import resources into terraform Ran some commands: ```sh terraform import aws_iam_policy.assume_role_s3_policy $TF_VAR_ASSUME_ROLE_POLICY ... terraform plan terraform apply ``` ### Further Exploration - [x] Snapshots & AMIs - [x] Create an EBS snapshot of `/dev/xvda` - [x] Register/create an AMI from that snapshot * I think with terraform we can combine the two steps and use `aws_ami_from_instance` to get the end result (create an AMI from snapshot) for free. Otherwise I think you would want to do [aws_ebs_snapshot](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ebs_snapshot) and then [aws_ami](https://registry.terraform.io/providers/hashicorp/aws/5.99.1/docs/resources/ami) ```sh resource "aws_ami_from_instance" "ami_snapshot" { name = "ami-snapshot-${formatdate("YYYY-MM-DD", timestamp())}" source_instance_id = aws_instance.my_first_linux.id snapshot_without_reboot = true tags = { Name = "labs" } } ``` ![ami creation](./assets/ami-creation.jpg) - [x] How do you "version" a server with snapshots? Why is this useful? * **Cattle, not pets** This is useful for following the concept for treating your servers as "cattle, not pets". Being able to keep versioned snapshots of your machines means there's nothing special about your currently running server. If it goes down (or you need to shoot it down), you can restore it on another machine from an older snapshot. Or, as another example, suppose you were tasked with installing a whole suite of tools on an ec2 instance (ex: fail2ban, ClamAV, etc.). Then your boss tells you the company needs the same setup for another 49 instances. Having 1 AMI that contains all of those tools can save you from re-running the same commands 50x times. - [x] Launch a new instance from your AMI Terraform is great. Terraform is life. This was really simple to do. ```sh # Launch new instance from AMI resource "aws_instance" "my_second_linux" { instance_type = "t2.micro" ami = aws_ami_from_instance.ami_snapshot.arn security_groups = ["ssh-access-witch"] tags = { Name = "labs" } } - [x] Convert to terraform * Terraform files can be found [here](./terraform/main.tf) ## Reflection * What I built * A secured s3 bucket for secure content that can only be accessed via multi-factor authentication Good for storing particularly sensitive information. * A minimal HTML website served from an S3 bucket * Challenges * The stretch goal for setting up s3 + mfa was a bit of a pain: * Groups cannot be used as the principal in a trust relationship so to get things working I added the trust relationship to my user's ARN instead. I prodded ChatGPT on a more practical way to do this (this wouldn't scale with 100s of users, onboarding/offboarding etc.) and had to go back and fix how the policies worked. * Issues between setting up Cloudflare -> CloudFront -> s3 bucket * I think adding an extra service (Cloudflare, where I host my domain) added a little bit of complexity, though my main issue was figuring out how to set up the ACM cert -> CloudFront distribution -> S3. Most of the instructions I was able to parse through with ChatGPT -- I have to say I had a much better reading through those instructions than with the official AWS docs, which led me through nested links (understandably, because there seem to be multiple ways of doing everything). * Security concerns Scale and security at scale I started out this lab doing "click-ops", and I noticed while testing connections that there was just a lot of trial and error in setting up permissions. My process seemed to be: OK, this seems pretty straightforward, let's just add the policy. But after adding the policy it looked like there was a cascade of errors where I forgot to add additional permissions or trust relationships that weren't immediately obvious until I actually went through the error logs one by one. Once everything got set up via click-ops and imported to terraform though, repeating the same steps via Terraform was *very easy*. I think putting everything down into code really helps to self-document the steps it takes to get a fully functioning setup. ## Terms ### Identity Access Management ```mermaid graph LR IAMPolicy -- attaches to --> IAMIdentity ExplainIAMIdentity[users, groups of users, roles, AWS resources]:::aside ExplainIAMIdentity -.-> IAMIdentity classDef aside stroke-dasharray: 5 5, stroke-width:2px; ``` ![Identity Access Management](./assets/mermaid.jpg)