Skip to main content

Security Model

Orchestr8 implements a defense-in-depth security model that provides multiple layers of protection for enterprise workloads. Security is built into every aspect of the platform, from cluster setup to application deployment.

Security Principles​

1. Zero Trust Architecture​

  • Never trust, always verify: Every request is authenticated and authorized
  • Least privilege access: Grant minimum required permissions
  • Network micro-segmentation: Isolate workloads at the network layer
  • Continuous verification: Monitor and validate security posture continuously

2. Security by Default​

  • Secure defaults: All components start with secure configurations
  • Automatic hardening: Platform applies security best practices automatically
  • Policy enforcement: Security policies are enforced, not optional
  • Fail secure: Systems fail to a secure state when errors occur

3. Compliance First​

  • Regulatory compliance: SOC 2, GDPR, HIPAA, PCI-DSS ready
  • Audit trails: Complete logging and monitoring of all activities
  • Data sovereignty: Control over data location and processing
  • Policy as code: Compliance rules defined and versioned in Git

Multi-Layer Security Architecture​

Identity and Access Management (IAM)​

Keycloak Integration​

Orchestr8 uses Keycloak as the central identity provider:

# Keycloak realm configuration
apiVersion: v1
kind: ConfigMap
metadata:
name: keycloak-realm
data:
realm.json: |
{
"realm": "orchestr8",
"enabled": true,
"sslRequired": "external",
"clients": [
{
"clientId": "kubernetes",
"enabled": true,
"protocol": "openid-connect",
"redirectUris": ["https://k8s.company.com/oauth/callback"]
}
]
}

Role-Based Access Control (RBAC)​

Cluster Roles​

  • cluster-admin: Full cluster access (break-glass only)
  • platform-admin: Platform management without cluster admin
  • developer: Application deployment and management
  • viewer: Read-only access to assigned resources
# Developer role with module-scoped permissions
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: orchestr8-developer
rules:
- apiGroups: [""]
resources: ["pods", "services", "configmaps"]
verbs: ["get", "list", "create", "update", "patch", "delete"]
- apiGroups: ["apps"]
resources: ["deployments", "replicasets"]
verbs: ["get", "list", "create", "update", "patch", "delete"]
- apiGroups: ["argoproj.io"]
resources: ["applications"]
verbs: ["get", "list", "update", "patch"]

Namespace-Based Isolation​

# RoleBinding for team-specific access
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: platform-team-binding
namespace: my-service
subjects:
- kind: User
name: platform-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: orchestr8-developer
apiGroup: rbac.authorization.k8s.io

Network Security​

Service Mesh (Istio)​

All inter-service communication is secured with mutual TLS:

# Automatic mTLS for all services
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: my-service
spec:
mtls:
mode: STRICT

Network Policies​

Default-deny network policies with explicit allow rules:

# Default deny all traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: my-service
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
---
# Allow specific ingress traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-ingress
namespace: my-service
spec:
podSelector:
matchLabels:
app: my-service
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
name: istio-system
ports:
- protocol: TCP
port: 8080

Traffic Encryption​

  • TLS termination at ingress gateway
  • mTLS for service-to-service communication
  • Certificate management via cert-manager
  • Automatic certificate rotation

Pod Security​

Pod Security Standards​

Orchestr8 enforces the restricted Pod Security Standard:

# Namespace with restricted security
apiVersion: v1
kind: Namespace
metadata:
name: my-service
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted

Security Context Requirements​

# Required security context
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-service
spec:
template:
spec:
securityContext:
runAsNonRoot: true
runAsUser: 65534
fsGroup: 65534
seccompProfile:
type: RuntimeDefault
containers:
- name: app
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsNonRoot: true
capabilities:
drop:
- ALL

Secret Management​

External Secrets Operator​

Integration with external secret management systems:

# External secret from AWS Secrets Manager
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: database-credentials
namespace: my-service
spec:
refreshInterval: 15s
secretStoreRef:
name: aws-secrets-manager
kind: SecretStore
target:
name: database-secret
creationPolicy: Owner
data:
- secretKey: username
remoteRef:
key: prod/database
property: username
- secretKey: password
remoteRef:
key: prod/database
property: password

Sealed Secrets​

For GitOps-friendly secret management:

# Create sealed secret
echo -n mypassword | kubectl create secret generic mysecret \
--dry-run=client --from-file=password=/dev/stdin -o yaml | \
kubeseal -o yaml > mysealedsecret.yaml

Image Security​

Container Image Scanning​

Automated vulnerability scanning with Trivy:

# Vulnerability scan policy
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-image-scan
spec:
validationFailureAction: enforce
background: false
rules:
- name: check-vulnerabilities
match:
any:
- resources:
kinds:
- Pod
validate:
message: "Image vulnerabilities exceed threshold"
pattern:
metadata:
annotations:
trivy.security.kubernetes.io/critical: "<=5"

Image Signing and Verification​

Using Sigstore/Cosign for image integrity:

# Sign container image
cosign sign --key cosign.key my-registry.com/my-app:v1.0.0

# Verify signature in admission controller
cosign verify --key cosign.pub my-registry.com/my-app:v1.0.0

Admission Controllers​

Policy enforcement at admission time:

# Gatekeeper constraint
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: k8srequiredlabels
spec:
crd:
spec:
names:
kind: K8sRequiredLabels
validation:
properties:
labels:
type: array
items:
type: string
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8srequiredlabels

violation[{"msg": msg}] {
required := input.parameters.labels
provided := input.review.object.metadata.labels
missing := required[_]
not provided[missing]
msg := sprintf("Label '%v' is required", [missing])
}

Compliance and Auditing​

Audit Logging​

Comprehensive audit trail of all cluster activities:

# Audit policy
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
resources:
- group: ""
resources: ["secrets", "configmaps"]
- level: Metadata
resources:
- group: ""
resources: ["pods", "services"]
- level: Request
verbs: ["create", "update", "patch", "delete"]

Compliance Scanning​

Automated compliance checks with Falco:

# Falco rule for privilege escalation
- rule: Launch Privileged Container
desc: Detect the initial process started in a privileged container
condition: >
spawned_process and container and k8s_audit and
ka.target.resource=pods and ka.verb=create and
ka.request_object contains privileged=true
output: >
Privileged container started (user=%ka.user.name verb=%ka.verb
resource=%ka.target.resource reason=%ka.response.reason)
priority: WARNING
tags: [kubernetes, security]

Data Protection​

Encryption at Rest​

  • etcd encryption: Kubernetes secrets encrypted in etcd
  • Volume encryption: Persistent volumes encrypted using cloud KMS
  • Database encryption: Application databases use TDE
# Encrypted storage class
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: encrypted-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp3
encrypted: "true"
kmsKeyId: "alias/kubernetes-encryption-key"

Data Classification​

Automatic data classification using labels:

# Sensitive data pod
apiVersion: v1
kind: Pod
metadata:
name: payment-processor
labels:
data-classification: "sensitive"
compliance-required: "pci-dss"
spec:
# Additional security controls applied automatically
securityContext:
runAsNonRoot: true
readOnlyRootFilesystem: true

Runtime Security​

Falco Runtime Monitoring​

Real-time threat detection:

# Falco configuration
apiVersion: v1
kind: ConfigMap
metadata:
name: falco-config
data:
falco.yaml: |
rules_file:
- /etc/falco/k8s_audit_rules.yaml
- /etc/falco/rules.d

json_output: true
json_include_output_property: true

# Send alerts to Slack/PagerDuty
program_output:
enabled: true
keep_alive: false
program: "curl -X POST slack-webhook-url"

Security Monitoring Dashboard​

Grafana dashboard for security metrics:

# ServiceMonitor for security metrics
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: security-metrics
spec:
selector:
matchLabels:
app: falco
endpoints:
- port: metrics
path: /metrics

Incident Response​

Security Incident Workflow​

  1. Detection: Automated alerts from Falco, network monitoring
  2. Assessment: Security team evaluates threat severity
  3. Containment: Automatic quarantine of affected workloads
  4. Eradication: Remove threats and patch vulnerabilities
  5. Recovery: Restore services with additional monitoring
  6. Lessons Learned: Post-incident review and policy updates

Automated Response​

# Automatic pod quarantine on security alert
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
name: security-incident-response
spec:
entrypoint: incident-response
templates:
- name: incident-response
steps:
- - name: quarantine-pod
template: quarantine
- - name: notify-security-team
template: alert

Security Best Practices​

Development​

  1. Shift-left security: Integrate security testing in CI/CD
  2. Threat modeling: Analyze security implications of design changes
  3. Code scanning: Static and dynamic analysis of application code
  4. Dependency scanning: Monitor for vulnerable dependencies

Operations​

  1. Regular updates: Keep all components updated with security patches
  2. Penetration testing: Regular security assessments
  3. Backup verification: Test backup and recovery procedures
  4. Access reviews: Regular review of user permissions and access

Monitoring​

  1. Security dashboards: Real-time visibility into security posture
  2. Alert tuning: Minimize false positives while catching real threats
  3. Log analysis: Centralized logging with security-focused queries
  4. Behavioral analysis: Detect anomalous behavior patterns

Next Steps​