A policy sitting in your AWS account grants nothing to anyone. It is a document until you attach it to a person, and that attach step is the moment the permissions become real. Day 19 had that on the AWS side, and its Linux twin, application files that do nothing until they land in the right directory and the server reloads.
One Linux task, one AWS task. Deploy a web application with Apache httpd, moving the files across with SCP, then attach an IAM policy to a user. The tasks come from the KodeKloud Engineer platform.
Apache: set the port, ship the files, reload
yum install -y httpd
systemctl enable --now httpd
# Point Apache at the required port
grep -n -i listen /etc/httpd/conf/httpd.conf
vi /etc/httpd/conf/httpd.conf # change Listen 80 to the required port
systemctl reload httpd
Apache's listen port lives in httpd.conf on the Listen line. Running grep with -n gives you the line number so you change that one directive and leave the rest alone. Then reload rather than restart, so the new port applies without dropping live connections. Next, the files:
# From the jump server, copy the app files over
sudo scp -r /home/thor/media user@stapp01:/tmp
sudo scp -r /home/thor/apps user@stapp01:/tmp
# On the app server, move them into the web root
mv /tmp/media /var/www/html/
mv /tmp/apps /var/www/html/
The files arrive from a jump server over scp, a two-hop pattern you see any time the app server has no direct internet access. They land in /tmp first, then move into the web root at /var/www/html. Nothing serves until the files are actually under the web root. Then confirm it:
curl -4 http://stapp01:<port>/media
curl -4 forces IPv4, which saves you from odd IPv6 resolution behavior in a dual-stack setup.
IAM: attaching is what makes a policy active
On AWS, the task was to attach an existing policy to a user. The policy already existed, the user already existed, and on their own they did nothing for each other. The attach is the wiring:
# Find the user and the policy
aws iam list-users
aws iam list-policies --no-only-attached --max-items 3
# Attach the policy to the user
aws iam attach-user-policy \
--user-name iam_userBob \
--policy-arn arn:aws:iam::123456789012:policy/my-policy
# Verify it stuck
aws iam list-attached-user-policies --user-name iam_userBob
The policy ARN is the exact identifier, and attaching the wrong one is how you hand out access you never meant to, so you check the ARN before attaching and list the attached policies after. And a callback to Day 17: this is exactly the case groups solve. Attaching directly to Bob works, but if five people need the same access you are back to five attach commands and five things to unpick later. Attach the policy to a group and add the users to the group instead.
Created is not connected
Both tasks share one quiet trap. Creating a thing and activating it are separate steps. The app files existed on the jump server and served nothing until they reached the web root. The policy existed in the account and granted nothing until it was attached. Half-finished work looks a lot like finished work, right up until you test it and nothing happens.
So here is the Day 19 question. When you call something done, do you mean the pieces exist, or do you mean you watched it work end to end?
Day 19 down. Eighty-one to go.
Top comments (1)
What a coincidence — I'm on Stratagem #19 and you're on Day 19. Looking forward to the day we both finish our series. I'll probably get there first, I've only got 17 more to go. Haha! 😄