Skip to content

CONCEPT Cited by 1 source

Customer-managed IAM footprint minimization

Customer-managed IAM footprint minimization is the architectural principle where a vendor's managed-service offering operates with the smallest possible IAM privilege set inside a customer's cloud account, achieved by transferring as much resource-creation authority as possible back to the customer so that the vendor's service role needs only runtime read/write access rather than resource-creation privileges.

Definition

The vendor deploys compute/agent into the customer's cloud account. Two broad postures:

  • Broader posture: vendor provisions VPC, subnets, security groups, IAM roles, storage buckets, DNS records, etc. Vendor's IAM role needs *:Create* / *:Delete* / *:Put* on many service principals. Larger blast radius if vendor role is compromised or misused.
  • Minimal posture: customer pre-provisions all of those resources. Vendor's IAM role needs only read-of-own-resources
  • write-to-pre-owned-storage + minimal runtime operations (e.g. ec2:AssociateAddress within vendor-owned subnet, s3:Put to vendor-assigned bucket prefix). Smaller blast radius.

The minimization is measured along multiple axes: number of distinct AWS actions granted, number of resource ARN patterns covered, presence of * wildcards in Resource or Action, and presence of IAM-resource-creation actions (iam:CreateRole, iam:PutRolePolicy, iam:CreateInstanceProfile).

Canonical instance

Redpanda BYOVPC is the canonical wiki instance. BYOVPC vs BYOC comparison from the 2026-03-11 GA post:

Axis BYOC BYOVPC
Redpanda IAM footprint "Broader (needs to create resources)" "Minimal (read/write only)"

Verbatim framing (Source: sources/2026-03-11-redpanda-redpanda-clouds-byovpc-for-aws-is-now-generally-available):

"Reduced IAM footprint for Redpanda (fewer permissions means a smaller blast radius)."

The mechanism: BYOVPC's Redpanda Cloud agent "doesn't create any new networking or IAM resources" — it only runs within the customer-defined substrate. Resource-creation authority stays with the customer's Terraform / CloudFormation / platform automation.

Design trade-offs

  • Customer ownership cost: the customer must have the platform capability to pre-provision the resources (Terraform module, IaC pipeline, platform team). BYOVPC ships with the Redpanda Terraform module to reduce this friction but doesn't eliminate it.
  • Vendor cold-start friction: the vendor's provisioning flow now has a "customer must provision substrate first" phase before cluster creation, vs "click deploy, wait 15 minutes" on the broader-posture variant.
  • Skip-what-you-have composition: partially-minimized posture is viable — the customer pre-provisions VPC + subnets (hard to share with vendor IAM ownership anyway) while letting the vendor still create the S3 bucket or IAM instance profiles. Supported via the Redpanda Terraform module's skip-variables.
  • Audit posture trade-off: minimal-footprint posture makes the vendor's actions easier to audit (fewer action types in CloudTrail from the vendor role) but also shifts configuration-drift detection responsibility to the customer.
  • Reduced blast radius — concepts/blast-radius generalises to the vendor-IAM-action space.
  • Principle of least privilege at integration boundary — this is the integration-boundary variant applied to vendor-customer-account relationships.
  • Composes with condition-tag IAM — BYOVPC also supports IAM condition tags for fine-grained scoping even within the minimal footprint.
  • Sovereignty adjunct — aligns with concepts/digital-sovereignty for customers who need regulator-auditable provenance of who-can-do-what in their AWS account.

Seen in

Last updated · 470 distilled / 1,213 read