Skip to content

CONCEPT Cited by 1 source

Security group profile

A security group profile is a layered, pre-approved set of AWS security-group rules that reflect an organisation's environment tiers (e.g. prod vs staging) or application roles (e.g. broker, agent, client), applied as a first-class attachable security posture rather than as flat, per-resource firewall rules.

Definition

Large organisations typically manage security posture via layered profiles rather than individually-configured security groups on each resource. A profile encodes:

  • Environment tier: prod-network-profile (stricter egress rules, tighter CIDR-range allowances), staging-network-profile (laxer rules, allowed inbound from developer workstations), etc.
  • Application role: broker-profile (Kafka-API ports 9092/9093 inbound from client-CIDR-only), agent-profile (outbound to control-plane only), client-profile (outbound to broker-profile only), etc.
  • Compliance overlay: PCI-profile (default-deny + audit-log requirement), HIPAA-profile (encryption-in-transit enforcement), etc.

Profiles are typically owned by a platform security team and reviewed / approved / versioned via policy-as-code (e.g. reviewed in a git repo, applied via Terraform modules or SCPs).

Vendor integration surface

When a managed-service vendor deploys compute into a customer's AWS account, the vendor's resources must either:

  1. Accept customer-attached profiles — the vendor's Cloud agent attaches customer-pre-provisioned security-group ARNs (encoding the profiles) to the vendor-deployed resources. The vendor never defines its own rules.
  2. Define its own security groups — the vendor manages rules independently; the customer must audit the vendor's rules against their organisation's profile scheme after-the-fact (or attempt to post-modify them, risking drift / revocation).

Posture (1) is what layered-profile-using organisations need. Posture (2) forces the organisation to treat the vendor as an exception to the profile scheme.

Canonical instance

Redpanda BYOVPC is the canonical wiki instance (posture 1). Verbatim from sources/2026-03-11-redpanda-redpanda-clouds-byovpc-for-aws-is-now-generally-available:

"Security group profiles: Rather than a flat set of rules, many organizations manage security posture through layered security group profiles that reflect environment tiers (e.g., prod vs. staging) or application roles (e.g., broker, agent, client). BYOVPC lets you attach these pre-approved profiles to Redpanda's resources, ensuring Redpanda fits into your existing security model rather than operating alongside it."

BYOC is posture 2 — Redpanda creates and manages the security groups, so the customer's layered profile scheme cannot be applied uniformly to Redpanda-deployed compute. BYOVPC lifts that restriction by transferring SG provisioning + attachment back to the customer.

Why profiles vs flat rules

Profiles bundle policy intent (prod vs staging, broker vs client) into a reusable, auditable unit. Flat per-resource rules:

  • Diverge over time (configuration drift) as individual resources evolve.
  • Are hard to audit at scale (which 500 resources comply with the PCI-profile intent? hard to tell from per-resource rules).
  • Cannot be revoked or rotated as a unit.

Profiles invert these: a single profile update propagates to every attached resource; audit is "which resources lack the prod-profile?" (easy query); rotation is "detach old profile, attach new profile, validate".

Trade-offs

  • Vendor cost: the vendor must support profile-ARN attachment rather than creating its own SGs. Forces the vendor to publish provisioning contracts ("we will attach whichever SGs you provide") rather than managing the posture internally.
  • Customer cost: the customer must provision and maintain the profiles as first-class artifacts. Platform-security capability required.
  • Drift avoidance: both sides must avoid post-deploy mutation of the SGs, or the profile-as-intent abstraction breaks.

Seen in

Last updated · 470 distilled / 1,213 read