The Art of Letting Go: Secure delegation of permissions in AWS environments

The talk walks through how a cloud security team let engineering teams create privileged IAM resources in AWS without manual approval for each request. The need grew out of a move away from hand-built server environments toward EKS clusters and a second cloud provider, which required IAM users for cross-cloud data flows and OIDC identity providers for Kubernetes service accounts. Both actions had been blocked at the organization level, so the speaker laid out the layers available for control: service control policies, identity policies, permission boundaries and resource policies.

For IAM users, the team gave the automation role a permission boundary that forces every user it creates to carry an approved boundary, and protected those boundaries with SCPs. A live demo showed that creating a user with the wrong boundary, or changing or removing one afterward, was refused. For OIDC providers, policies alone could not stop a provider from being created in the wrong account, so an EventBridge rule in each account forwarded events to a central bus. A Lambda function there checked the provider type, principal, thumbprint and account, then removed the provider and sent an alert when a check failed.

The closing section covered the trade-offs. Per-account limits on IAM users make the approach hard to scale, and long-term keys required rotation. The team planned to replace those users with IAM Roles Anywhere and to restrict source IPs for the credentials that remained. The main takeaway is to pair scoped delegation with automated detection and remediation, so teams can move quickly while security keeps visibility.