Labs · Cyber Security

Lab: Security Review of Your Reels App – Find Secrets in Code, Use a Least-Privilege IAM Role and Confirm RDS Is Private

By Ravindra Bagale · Last updated: 8 October 2026

Suppose we are…

Suppose our team built a short-video app like Instagram Reels as the Chapter 16 project: the app runs on EC2, videos go to S3 and user data is in RDS. Before the demo to the client, the Tech Mahindra security lead asks three questions: "Any AWS keys or DB passwords in Git? What can the server's IAM role do? Is RDS reachable from the internet?" We answer each one with evidence.

Goal of this lab

By the end you will have:

• Searched your code and its Git history for secrets.
• The app server using an IAM role (temporary credentials given to the server by AWS) that can only read and write one S3 bucket, with no access keys on disk.
• Evidence that RDS is not public and the S3 bucket blocks public access, written as a short review note.

What you need (all free)

• Your own Chapter 16 project folder with Git (any of your own Git projects also works for Part 1).
• Your AWS account, if the project is still deployed. If you deleted it, do Part 1 on the code and read Parts 2–3 as a checklist.
• 45–50 minutes.

Part 1: secrets in code and history

1. Open a terminal in your project folder. Search the current code for common secret patterns:

   git grep -nE "AKIA[0-9A-Z]{16}|aws_secret_access_key|DB_PASSWORD|password *=" 
   

   👁 What you should see: no lines (good), or the file and line number of each match to review.

2. Search the whole history, because a key deleted last week is still in old commits:

   git log -p --all | grep -nE "AKIA[0-9A-Z]{16}|aws_secret_access_key" | head
   

3. Check that secret files are ignored by Git:

   cat .gitignore
   git check-ignore -v .env
   

   👁 What you should see: .gitignore:1:.env .env (or similar). If there is no output, add a line .env to .gitignore.

4. If you found a real key in step 1 or 2: IAM → Users → the user → Security credentials → Access keys → Actions → Deactivate, then delete it, then fix the code to read secrets from environment variables or AWS Secrets Manager.

Part 2: least-privilege IAM role

5. On the EC2 server, check for stored keys (there should be none when a role is used):

   ls -la ~/.aws/ 2>/dev/null; env | grep -i aws_secret
   aws sts get-caller-identity
   

   👁 What you should see: no credentials file and no secret in the environment, and an Arn like arn:aws:sts::123456789012:assumed-role/reels-app-role/i-0abc.... assumed-role means the server uses a role.

6. In IAM → Roles → reels-app-role (or create one: Create role → AWS service → EC2) → Add permissions → Create inline policy → JSON and use a policy that allows only your bucket (replace the name):

   {
     "Version": "2012-10-17",
     "Statement": [{
       "Effect": "Allow",
       "Action": ["s3:GetObject", "s3:PutObject"],
       "Resource": "arn:aws:s3:::reels-videos-yourname/*"
     }]
   }
   

7. Remove broad policies such as AmazonS3FullAccess or AdministratorAccess from the role. Attach the role to the server: EC2 → instance → Actions → Security → Modify IAM role.

8. Test from the server:

   echo test > t.txt && aws s3 cp t.txt s3://reels-videos-yourname/t.txt
   aws s3 ls
   

   👁 What you should see: the upload succeeds, but aws s3 ls (list all buckets) fails with AccessDenied. The role can do only what the app needs.

Part 3: data stores private

9. In CloudShell, check RDS and S3:

   aws rds describe-db-instances --query "DBInstances[].[DBInstanceIdentifier,PubliclyAccessible]" --output table
   aws s3api get-public-access-block --bucket reels-videos-yourname
   

   👁 What you should see: False for your database, and all four Block Public Access settings true.

10. Write a 6-line review note: secrets in code (yes/no, fixed?), secrets in history, .env ignored, role used and scoped to one bucket, RDS private, S3 public access blocked.

Common mistakes

Self-check checklist

Try-at-home challenge

Add a Git pre-commit hook that stops a commit if the staged changes contain AKIA. Test it with a fake line AKIAFAKEFAKEFAKEFAKE.

cat > .git/hooks/pre-commit <<'H'
#!/bin/sh
if git diff --cached | grep -qE "AKIA[0-9A-Z]{16}"; then
  echo "Blocked: possible AWS access key in staged changes"; exit 1
fi
H
chmod +x .git/hooks/pre-commit

Clean up to avoid charges

If the Reels app is still deployed and you no longer need it: terminate the EC2 server, delete the RDS database (no final snapshot), empty and delete the S3 bucket, release any Elastic IP, and delete the IAM role.

Samjla ka? No secrets in Git, a role with one bucket, and private data stores, with evidence. Aata pudhe jaauya: Chapter 17 explains why we learnt all this before Kali Linux.