Identity, resource, and boundary
1. Identity, resource, and boundary
The last video ended with a verified token, and a verified token tells you who somebody is. It does not tell you what they may reach. That second decision is authorization, and this video maps where policies live and how you scope one to a tenant.2. Which policy is in charge?
Picture this: you add the missing permission, and the call still fails. In chapter one that had two answers: an explicit deny, or no allow at all. Here there is a third, because no single policy is in charge.3. Which policy is in charge?
Up to three layers can weigh in: an identity policy on the caller, a resource policy on the resource, and above them a permissions boundary that only ever takes away. Not every request meets all three. A deny at any layer it meets ends it.4. Two places a policy can live
Two of those layers grant permissions, so start there. An identity-based policy attaches to the caller, a user or a role, and lists what that identity may do. It is a pass you wear.5. Two places a policy can live
A resource-based policy attaches to the resource instead, like an S3 bucket, and lists who may touch it. It is a guest list on one door. You need one when the caller lives outside your account, because you cannot attach a policy to someone else's identity.6. Managed for you, or by you
Identity-based policies come in two kinds. An AWS managed policy is written by AWS, off the rack and broader than you need. A customer managed one you write and own, scoped to the task.7. Managed for you, or by you
The trade-off is convenience against precision. Reach for managed on a common job, and write your own when least privilege matters, which in production is most of the time.8. A boundary caps what a policy grants
Every policy so far grants. Organizations attach a boundary so developers can create their own roles without granting themselves more than the account allows. It sets a ceiling on what a role's policies can ever grant. Effective permissions are what the policy and the boundary both allow.9. A boundary caps what a policy grants
Now the opening failure makes sense. You added IAM CreateUser to the role's own policy, but the boundary never allowed IAM, so no edit to that policy can reach it. It is like a card's spending limit: the store approves, but the limit declines.10. A boundary caps what a policy grants
A session policy caps the same way, but only for one session. You pass it inline on the AssumeRole call, so the credentials that come back are narrower than the role itself. That is how one backend serves many tenants from a single role.11. A condition narrows the allow
Until now, an allow has covered a whole action on a whole resource. A condition key makes one precise. The same request is then allowed from one place and denied from another.12. A condition narrows the allow
When the value a condition matches is a tag on the caller, the pattern is called attribute-based access control, or ABAC. One policy then serves many principals, which is how tenant isolation scales.13. One table, one tenant at a time
A multi-tenant application keeps every customer's rows in one shared DynamoDB table, Amazon's managed key-value database. It files every row under a partition key, one value per tenant. One table is not isolation, so what keeps tenant A out of tenant B's rows?14. One table, one tenant at a time
One condition narrows the gap. dynamodb:LeadingKeys says the partition key on the request must match the tenant tag on the caller, so a query can only return that tenant's rows. ForAllValues means every partition key the request supplies has to match. Like a shared mailroom, your key opens only your box.15. One table, one tenant at a time
There is a hole, and it is the one people ship. This condition can only judge a request that names a partition key. A Scan carries none, so there is no value for it to fail on, and it passes. AWS says it plainly: a Scan returns all items regardless of the leading keys. The condition cannot close that for you.16. Let's practice!
Time to practice choosing between identity, resource, and boundary.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.