Introduction to AWS Security
1. Introduction to AWS Security
Welcome to AWS Security for Developers. This course was developed by Rahul, a Technical Product Manager. Who has shipped products across several industries, and through that learned that security has to live in your everyday work, not get bolted on at the end.2. Course prerequisites
Before we dive into this course, it is recommended to have basic knowledge around AWS security, and cloud computing concepts. We'd recommend taking AWS Security and Cost Management Concepts before starting this course.3. Course objectives
Here is the ground this course covers. Identity: who is calling, and what they may reach. Authorization: where the rules live and how you scope them. Secrets and encryption: protecting credentials and data. Evidence: proving what happened. We start with identity.4. Your code ships through a pipeline
First, one piece of vocabulary you'll hear throughout. A pipeline is the automation that builds, tests, and deploys your code after you push. It runs on its own, under an identity of its own. That last detail is where our story begins.5. A deploy that fails for the wrong reason
Here's a question underneath almost every security decision: when your code calls AWS, whose permissions are actually being checked? You've probably lived this moment. You push a change,6. A deploy that fails for the wrong reason
the pipeline runs,7. A deploy that fails for the wrong reason
and the deployment fails with an access denied error. The instinct is to check your own permissions, since you're the one staring at the failure. It's almost always wrong.8. What actually happened
So let's follow what happened, one step at a time. You pushed a change, and your involvement ended there.9. What actually happened
Your pipeline picked up the change and ran the deployment using an identity of its own, one that you or your team created for it.10. What actually happened
When the pipeline called AWS, AWS evaluated that identity, not you. Checking your own permissions was never going to explain the failure.11. Actor and principal
Two concepts matter here. The actor is whoever set the work in motion, which here is you.12. Actor and principal
The principal is the identity AWS evaluates when the request arrives, which here is the role your pipeline runs as. Think of a courier delivering a package: you set it in motion, but the building's security desk checks the courier's badge, not yours.13. Actor and principal
Almost nothing you build runs as you personally. A Lambda function runs under an execution role, the identity Lambda gives it for AWS calls. A container on ECS runs under a task role, the same idea. Pipelines run under their own roles. The name changes per service; the principal does not. The exception is your own terminal: a long-lived key there belongs to an IAM user, and that user is the principal.14. Same deploy, two roles
Once you know a role gets checked, the question is what it may do. Picture two roles that deploy the same application. The first reads every bucket, uses every key, updates every function. The second reads one prefix, a folder-like path inside a single bucket, uses one key, updates one function. Both ship your change, and the deployment log looks identical.15. Blast radius
Blast radius is what a role can reach when something goes wrong: a leaked credential, a compromised dependency, unintended code. A wide role reaches the whole account. A narrow role stops at one prefix in one bucket, like a fire door holding a fire to a single room. Same mistake, same incident, but the fallout was decided when someone chose the permissions.16. Least privilege, in practice
That is least privilege: a role does what its job requires and very little more. A key that opens one room, not the building master key. This reports-bucket role reads and lists objects. No deletes, no blanket decrypt, no touching Identity and Access Management, IAM, the service that decides who may do what. AWS managed policies are written for every account; a customer managed policy is yours to write. Scope lifetime too: short-lived credentials over long-lived keys. AWS secures the infrastructure; how broad your roles are is your call. Next time, ask: if this identity were misused tomorrow, what is the worst it could do?17. Let's practice!
Time to put actor and principal into practice with some exercises.Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.