Security in IDPs: An Integrated Approach
Security in an Internal Developer Platform is not an additional layer to apply after the fact: it must be integrated by design into every platform component. The Zero Trust paradigm ("never trust, always verify") is the architectural foundation of a secure platform: every request, every access, and every communication is verified, regardless of origin.
The challenge for platform teams is balancing security with developer experience: overly restrictive policies slow development and incentivize insecure workarounds, while overly permissive policies expose the organization to risk. The solution is security automation: automatic policy enforcement that protects without being an obstacle.
What You'll Learn
- Zero Trust principles applied to IDPs
- RBAC and ABAC for granular access control
- Policy enforcement with OPA and Kyverno
- Automated secret management with Vault
- Supply chain security: SBOM, image signing, vulnerability scanning
- Compliance frameworks: GDPR, SOC2, ISO 27001
Zero Trust Architecture
The Zero Trust model is based on fundamental principles that must be implemented at every platform level:
- Verify explicitly: every request is authenticated and authorized, even from the internal network
- Least privilege access: every user and service has the minimum permissions necessary for their function
- Assume breach: the platform is designed assuming a compromise can occur, minimizing the blast radius
In the Kubernetes context, Zero Trust translates to: mandatory mTLS between services (service mesh), network policies blocking unauthorized traffic, pod security standards preventing privileged container execution, and audit logging of every operation.
# Zero Trust: Kubernetes network policies
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: checkout-service-policy
namespace: checkout
spec:
podSelector:
matchLabels:
app: checkout-service
policyTypes:
- Ingress
- Egress
ingress:
# Only from gateway and orders service
- from:
- namespaceSelector:
matchLabels:
name: api-gateway
- namespaceSelector:
matchLabels:
name: orders
ports:
- protocol: TCP
port: 8080
egress:
# Only to database, cache, and required services
- to:
- namespaceSelector:
matchLabels:
name: databases
ports:
- protocol: TCP
port: 5432
- to:
- namespaceSelector:
matchLabels:
name: cache
ports:
- protocol: TCP
port: 6379
# DNS resolution
- to:
- namespaceSelector:
matchLabels:
name: kube-system
ports:
- protocol: UDP
port: 53
---
# Pod Security Standard: restricted
apiVersion: v1
kind: Namespace
metadata:
name: checkout
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
RBAC and ABAC: Granular Access Control
Access control in the platform must be granular and automated:
- RBAC (Role-Based Access Control): assigns permissions based on predefined roles (developer, tech lead, platform admin)
- ABAC (Attribute-Based Access Control): permissions based on dynamic attributes (team, environment, time, location)
- Just-In-Time access: temporary access to privileged resources with approval and automatic expiration
- Break-glass procedures: emergency procedures for elevated access with complete audit
# RBAC: Kubernetes roles for the platform
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: platform-developer
rules:
# Can view and manage their own deployments
- apiGroups: ["apps"]
resources: ["deployments", "replicasets"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
# Can view pods but not delete them
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
# Can manage configmaps and secrets in their namespace
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
# CANNOT modify namespaces, RBAC, or network policies
- apiGroups: [""]
resources: ["namespaces"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: team-checkout-developer
namespace: checkout
subjects:
- kind: Group
name: team-checkout
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: platform-developer
apiGroup: rbac.authorization.k8s.io
Automated Policy Enforcement
Policies must be automatically enforced, not left to developer goodwill. The two main tools for policy enforcement in Kubernetes are:
- OPA/Gatekeeper: general-purpose policy engine with Rego language. Powerful but with a steep learning curve
- Kyverno: Kubernetes-native policy engine using YAML. Simpler and more intuitive for K8s-specific policies
# Kyverno: platform security policies
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-non-root
spec:
validationFailureAction: Enforce
rules:
- name: run-as-non-root
match:
any:
- resources:
kinds:
- Pod
validate:
message: "Containers must run as non-root"
pattern:
spec:
containers:
- securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-resource-limits
spec:
validationFailureAction: Enforce
rules:
- name: require-limits
match:
any:
- resources:
kinds:
- Pod
validate:
message: "All containers must have resource limits"
pattern:
spec:
containers:
- resources:
limits:
memory: "?*"
cpu: "?*"
requests:
memory: "?*"
cpu: "?*"
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-labels
spec:
validationFailureAction: Enforce
rules:
- name: require-team-label
match:
any:
- resources:
kinds:
- Deployment
- StatefulSet
validate:
message: "All workloads must have 'team' label"
pattern:
metadata:
labels:
team: "?*"
app: "?*"
Supply Chain Security
Supply chain security protects the entire software lifecycle, from dependency to deployment:
- SBOM (Software Bill of Materials): complete inventory of all dependencies for every service, automatically generated
- Image signing: cryptographic signing of container images with Cosign/Sigstore to guarantee integrity
- Vulnerability scanning: automatic image scanning with Trivy, Snyk, or Grype integrated into CI/CD
- Admission control: only signed and scanned images can be deployed to the cluster
Security Automation Principle
If a security policy requires manual action from the developer, it will fail. Security must be automated: scanning in CI/CD, policy enforcement in admission controllers, automatic secret rotation, automatic certificate renewal. The developer should not have to think about security: the platform handles it for them.
Compliance Frameworks
Modern IDPs must support compliance with regulatory frameworks:
- GDPR: data encryption, access logging, data retention policies, right to deletion
- SOC 2: security controls, availability, processing integrity, confidentiality, privacy
- ISO 27001: information security management system, risk assessment, continuous improvement
- PCI DSS: for platforms handling payment data
The platform should make compliance continuous and automatic: automatic audit trails, real-time policy enforcement, automatically generated compliance reports. This transforms compliance from a stressful annual audit into a continuous, painless process.
Audit Logging and Monitoring
A comprehensive audit logging system is the foundation for security and compliance:
- Immutable logs: audit logs must be immutable and retained for the period required by compliance
- Centralized logging: all security logs flow into a centralized system (SIEM)
- Real-time alerting: immediate alerts for critical security events (suspicious access, privilege escalation)
- Forensic capability: ability to reconstruct the sequence of events in case of a security incident
# Audit logging: Kubernetes audit policy
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# Log all secret access
- level: Metadata
resources:
- group: ""
resources: ["secrets"]
# Log all RBAC modifications
- level: RequestResponse
resources:
- group: "rbac.authorization.k8s.io"
resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]
# Log all deletes
- level: RequestResponse
verbs: ["delete", "deletecollection"]
# Log all pod exec
- level: Request
resources:
- group: ""
resources: ["pods/exec", "pods/attach"]
# Minimal logging for frequent read requests
- level: None
resources:
- group: ""
resources: ["events", "nodes/status"]
verbs: ["get", "list", "watch"]
Security by Default
The most secure configuration must be the default configuration. Golden Paths must include built-in security best practices: non-root containers, resource limits, network policies, secret management via Vault. Developers following the Golden Path get security without additional effort.