I Wrote a Security Policy, Then Made Myself Break It
A guardrail you haven't tried to violate is just documentation with better formatting. A member account, dev-workload, gets native AdministratorAccess inside its own boundary.
Useful takeaways from this story.
A guardrail you haven't tried to violate is just documentation with better formatting.
A member account, dev-workload, gets native AdministratorAccess inside its own boundary.
Access is brokered exclusively through short-lived STS AssumeRole sessions, zero static IAM user access keys allowed.
Building the complete brief
The page is ready to read now. The fuller skim-friendly version will appear here automatically.
The useful part
A guardrail you haven't tried to violate is just documentation with better formatting. A member account, dev-workload, gets native AdministratorAccess inside its own boundary. Access is brokered exclusively through short-lived STS AssumeRole sessions, zero static IAM user access keys allowed.
How it works
- The experiment focuses on the gap between what AdministratorAccess implies on paper and what an SCP actually enforces at the API evaluation layer underneath it.
- <a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cfo...
Details worth keeping
That's the premise behind aws-boundary: an AWS multi-account setup using AWS Organizations, where a management account defines security guardrails and a separate member account operates under full administrator access, yet remains strictly bound by policies it cannot edit, bypass, or disable.
Keep reading in the app
Open the app view to save this story, compare related coverage, and continue from the same source.