c# meeting #1 - my-armageddon-project-1
- Larry Harris
- Kelly D Moore
- Dennis Shaw
- Logan T
- Tre Bradshaw
- Bryce Williams
- Jasper Shivers (Jdollas)
- Ted Clayton
- Torray
- Zeek-Miller
- Jay Mallard
- created and instructed everyone to create a Terraform repo in Github to share notes and test the Terraform builds
- went through Lab 1a discussed, seperated Larry's main.tf into portions. We tested trouble shot, spun up the code. Dennis will upload to github and after Larry looks through it, will make it available for everyone to download
- everyone inspect, test and come back with any feedback, suggestions and or comments
- Here is the 1st draft diagram. We want to hear if you guys have any feedback or suggestions for this as well.
VPC name == bos_vpc01
Region = US East 1
Availability Zone
- us-east-1a
- us-east-1b
- CIDR == 10.26.0.0/16
| Subnets | ||
|---|---|---|
| Public | 10.26.101.0/24 | 10.26.102.0/24 |
| Private | 10.26.101.0/24 | 10.26.102.0/24 |
-
Security Groups for RDS & EC2
- RDS (ingress)
- mySQL from EC2
-
EC2 (ingress)
- student adds inbound rules (HTTP 80, SSH 22 from their IP)
*** reminder change SSH rule!!!
- Larry Harris
- Dennis Shaw
- Jasper Shivers (Jdollas)
- David McKenzie
- Ted Clayton
- LT (Logan T)
- Review meeting 1
- make sure everyone has their github setup
-
- note - recursive error when you re-upload this build you will get an error:
- "You can't create this secret because a secret with this name is already scheduled for deletion." AWS keeps the secret by default for 30 days after you destroy. Therefore run this code to delete now after each terraform destroy
aws secretsmanager delete-secret --secret-id bos/rds/mysql --force-delete-without-recovery
-
- variables.tf - line 40 verify the correct AMI #
- variables.tf - line 46 verfify if you are using T2.micro or T3.micro
- variables.tf - line 83 use your email
- delete providers.tf because it is duplicated in the auth.tf
- output.tf - line command out the the last two blocks (line 22-27)
- JSON file - replace the AWS account with your personal 12 digit AWS account#
- go through the expected lab 1a deliverables. Starting at #4 on the 1a_explanation.md in Theo's armageddon.
Theo's outline
- showing the logical flow
- A user sends an HTTP request to an EC2 instance
- The EC2 application:
- Retrieves database credentials from Secrets Manager
- Connects to the RDS MySQL endpoint
- Data is written to or read from the database
- Results are returned to the user
- and satisfying the security model
- RDS is not publicly accessible
- RDS only allows inbound traffic from the EC2 security group
- EC2 retrieves credentials dynamically via IAM role
- No passwords are stored in code or AMIs
My flow query
- user -> the internet gateway attached to the VPC to the EC2 inside an AZ us-east-1a inside a Public Subnet, the EC2 has IAM roles attached, also, the EC2 in the public subnet -> SNS inside the Region US East 1 to the email Alert system administered by the SNS outside the Region east 1, also, the EC2 -> to the VPC endpoint -> secrets manager inside region US East 1 but outside of the AZ of us-east-1a, -> RDS inside the Private subnet inside us-east-1a -> Nat Gateway to the internet gateway to the user
Verified flow concept
- User request is initiated from the internet.
- The request passes through the Internet Gateway (IGW) attached to the VPC.
- The traffic is routed to the EC2 instance in the public subnet (using its public IP/DNS).
- The EC2 instance processes the request, communicates internally with Secrets Manager via a VPC endpoint to retrieve database credentials, and then connects to the RDS instance in the private subnet to query or store data.
- The RDS instance sends the data back to the EC2 instance over the private network.
- The EC2 instance generates a response and sends it back out through the Internet Gateway (IGW) to the User over the internet.
- Separately, if an alert is triggered, the EC2 instance connects to the SNS regional endpoint (either via the IGW or a separate VPC endpoint) to send a notification, which SNS then delivers to the external email system. The NAT gateway is not typically involved in either of these primary request/response paths.
-
In RDS console, copy the endpoint (you won’t paste it into app because Secrets Manager provides host)
-
EC2 instance running and reachable over HTTP
- go to your browser add http:// and and your public IP
- shows RDS MySQL in the same VPC
-
Security group rule showing:
- RDS inbound TCP 3306
- Source = EC2 security group (not 0.0.0.0/0)
- IAM role attached to EC2 allowing Secrets Manager access
- Successful database initialization
- Ability to insert records into RDS
- Ability to read records from RDS
- Screenshot of:
- RDS SG inbound rule using source = sg-ec2-lab
- EC2 role attached
- http://<EC2_PUBLIC_IP>/ini
- http://<EC2_PUBLIC_IP>/add?note=first_note
- http://<EC2_PUBLIC_IP>/list
-
If /init hangs or errors, it’s almost always: RDS SG inbound not allowing from EC2 SG on 3306 RDS not in same VPC/subnets routing-wise EC2 role missing secretsmanager:GetSecretValue Secret doesn’t contain host / username / password fields (fix by storing as “Credentials for RDS database”)
-
list output showing at least 3 notes
go to instances > connect > Session manager (because its in a private subnet you can't access this though public internet) > connect
- copy and paste this command in the command line
- mysql -h bos-rds01.cmls2wy44n17.us-east-1.rds.amazonaws.com -P 3306 -u admiral -p (you can get this from the command line in vscode in the output section)
You are expected to prove your work using the CLI — not screenshots alone.
aws ec2 describe-instances --filters "Name=tag:Name,Values=bos-ec201" --query "Reservations[].Instances[].{InstanceId:InstanceId,State:State.Name}"
- Instance ID returned
- Instance state = running
aws ec2 describe-instances
--instance-ids <INSTANCE_ID>
--query "Reservations[].Instances[].IamInstanceProfile.Arn"
- ARN of an IAM instance profile (not null)
aws rds describe-db-instances
--db-instance-identifier bos-rds01
--query "DBInstances[].DBInstanceStatus"
Available
aws rds describe-db-instances
--db-instance-identifier bos-rds01
--query "DBInstances[].Endpoint"
- Endpoint address
- Port 3306
aws ec2 describe-security-groups --filters "Name=tag:Name,Values=bos-rds-sg01" --query "SecurityGroups[].IpPermissions"
- TCP port 3306
- Source referencing EC2 security group ID, not CIDR
SSH into EC2 and run:
aws secretsmanager get-secret-value --secret-id bos/rds/mysql expected result
- JSON containing:
- username
- password
- host
- port
Install MySQL client (temporary validation): sudo dnf install -y mysql
mysql -h <RDS_ENDPOINT> -u admin -p
- go to council and connect instance. Code must be run in the AWS terminal (connect > session manager > connect)
- go to council > rds > databases > DB identifier > connectivity and security - then copy endpoint paste in code. Enter password Broth3rH00d hit return
Expected:
- Successful login
- No timeout or connection refused errors
-
A. Why is DB inbound source restricted to the EC2 security group?
- Restricting database inbound traffic to an EC2 security group is a fundamental security best practice
-
B. What port does MySQL use?
- Port 3306
-
C. Why is Secrets Manager better than storing creds in code/user-data?
- It centrally stores, encrypts, and manages secrets with automatic rotation and fine-grained access controls, eliminating hardcoded credentials in code/user-data, which significantly reduces the risk of exposure and simplifies lifecycle management.
- Larry Harris
- Dennis Shaw
- Kelly D Moore
- Bryce Williams
- Eugene
- LT (Logan T)
- NegusKwesi
- Torray
- Tre Bradshaw
- Ted Clayton
- inline_policy.json
- line 19 create an IAM policy referencing the json from our folder
- comment out line 26-29 in ec2.tf
add: resource "aws_iam_role_policy" "bos_ec2_secrets_access" { name = "secrets-manager-bos-rds" role = aws_iam_role.bos_ec2_role01.id
policy = file("${path.module}/00a_inline_policy.json") }
- make sure everyone is caught up
- go over all deliverables so that everyone can take screenshots
Lab 1a complete!



















