Security

Kubernetes Security Model

Threat model and security architecture for managed Kubernetes clusters

Managed Kubernetes clusters on tasmanian.cloud run Cozystack with Talos OS. This document outlines the security model for cluster isolation, workload security, and multi-tenancy.


Security Goals

The Kubernetes security model aims to provide:

  • Cluster isolation — Complete separation between customer clusters
  • Workload isolation — Pods cannot access other pods or the host
  • Supply chain security — Verified images and configurations
  • Secret management — Secure handling of credentials and tokens
  • Observability — Audit logging and runtime threat detection
  • Zero-trust networking — Every connection authenticated and authorized

Threat Model

In Scope (Threats We Protect Against)

  • Container escape — Pods breaking out to host or other pods
  • Privilege escalation — Gaining cluster-admin from limited access
  • Network attacks — Pod-to-pod attacks, service enumeration
  • Secret exfiltration — Unauthorized access to Kubernetes secrets
  • API server abuse — DoS, privilege escalation via RBAC
  • Supply chain attacks — Compromised images or Helm charts
  • Cryptojacking — Unauthorized mining workloads
  • Lateral movement — Moving between namespaces or clusters
  • Etcd data exposure — Direct access to cluster state database

Out of Scope (Threats We Do Not Protect Against)

  • Compromised kubeconfig — If customer leaks their credentials
  • Vulnerable applications — Customer workloads with CVEs
  • Misconfigured RBAC — Customers granting excessive permissions
  • Malicious container images — Customer-deployed images we don't control
  • Insider threats with admin access — Cluster admins can access anything
  • Side-channel attacks — CPU/memory side channels between pods
  • Physical attacks — Cold boot, hardware implants
  • Control plane compromise — If etcd/API server is compromised

External Threat Overview

Architecture Components

┌─────────────────────────────────────────────────────────────────┐
│                    Management Cluster                           │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │              Cluster API (CAPI) Controller              │   │
│  │         Manages lifecycle of customer clusters          │   │
│  └─────────────────────────────────────────────────────────┘   │
│                              │                                  │
└──────────────────────────────┼──────────────────────────────────┘

          ┌────────────────────┼────────────────────┐
          │                    │                    │
   ┌──────▼──────┐     ┌──────▼──────┐     ┌──────▼──────┐
   │  Customer   │     │  Customer   │     │  Customer   │
   │  Cluster A  │     │  Cluster B  │     │  Cluster C  │
   │             │     │             │     │             │
   │ ┌─────────┐ │     │ ┌─────────┐ │     │ ┌─────────┐ │
   │ │Control  │ │     │ │Control  │ │     │ │Control  │ │
   │ │Plane    │ │     │ │Plane    │ │     │ │Plane    │ │
   │ │(3 nodes)│ │     │ │(3 nodes)│ │     │ │(3 nodes)│ │
   │ └────┬────┘ │     │ └────┬────┘ │     │ └────┬────┘ │
   │      │      │     │      │      │     │      │      │
   │ ┌────▼────┐ │     │ ┌────▼────┐ │     │ ┌────▼────┐ │
   │ │ Worker  │ │     │ │ Worker  │ │     │ │ Worker  │ │
   │ │ Nodes   │ │     │ │ Nodes   │ │     │ │ Nodes   │ │
   │ │(Talos)  │ │     │ │(Talos)  │ │     │ │(Talos)  │ │
   │ └─────────┘ │     │ └─────────┘ │     │ └─────────┘ │
   └─────────────┘     └─────────────┘     └─────────────┘

Trust Boundaries

Untrusted:

  • Customer workloads (pods, containers)
  • Customer-supplied container images
  • Customer RBAC configurations
  • Third-party Helm charts

Semi-Trusted:

  • Cluster API controllers (can create/delete clusters)
  • FluxCD (can modify cluster state)
  • Cilium (has network visibility)

Trusted:

  • Talos OS (immutable, API-managed)
  • Kubernetes control plane (etcd, API server)
  • Management cluster (runs CAPI)

Talos OS Security

Talos provides a minimal, immutable operating system:

FeatureSecurity Benefit
Immutable filesystemNo persistence of malware
No SSHNo interactive access attack surface
API-only managementAll changes logged, auditable
Minimal attack surfaceFewer packages = fewer CVEs
Automated updatesFast patching without downtime
TPM integrationMeasured boot, secure enrollment

Internal Threat Overview

Pod Security

Clusters enforce the Restricted Pod Security Standard:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Enforced policies:

  • Pods must run as non-root
  • No privilege escalation allowed
  • All capabilities dropped
  • Read-only root filesystem required
  • Seccomp profiles required
  • No host namespaces (PID, IPC, Network)
  • No host path mounts

Network Security (Cilium)

Cilium provides eBPF-based networking and security:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  endpointSelector: {}
  ingressDeny:
  - {}
---
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-frontend-to-api
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP

Network security features:

  • Default deny all traffic
  • Identity-based policies (not IP-based)
  • L7 filtering (HTTP, gRPC, Kafka)
  • WireGuard encryption for pod-to-pod
  • DNS-based policies

RBAC Architecture

Default roles provided to customers:

RolePermissions
cluster-adminFull cluster access (use sparingly)
namespace-adminFull access within a namespace
developerDeploy apps, read secrets, view logs
viewerRead-only access to resources
ciDeploy only, no secret access

Best practices enforced:

  • Service accounts per workload
  • No default service account usage
  • Least privilege principle
  • Regular access reviews

Secret Management

Secrets are encrypted at rest and in transit:

# etcd encryption configuration
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
    - secrets
    - configmaps
    - ingresses.extensions
    providers:
    - aescbc:
        keys:
        - name: key1
          secret: <base64-encoded-32-byte-key>
    - identity: {}

Secret handling:

  • External Secrets Operator for cloud secrets
  • Sealed Secrets for GitOps
  • Short-lived service account tokens
  • No secrets in environment variables (use files)

Runtime Security (Tetragon)

Tetragon provides eBPF-based runtime security:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detect-cryptomining
spec:
  kprobes:
  - call: "__x64_sys_execve"
    syscall: true
    args:
    - index: 0
      type: "string"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Prefix"
        values:
        - "/tmp/xmrig"
        - "/tmp/minerd"
      matchActions:
      - action: Sigkill

Runtime protections:

  • Process execution monitoring
  • File integrity monitoring
  • Network connection tracking
  • Privilege escalation detection
  • Automatic response (kill, notify)

Cluster Isolation

Each customer cluster is completely isolated:

LayerIsolation Mechanism
ComputeSeparate VMs per cluster
NetworkSeparate Cilium meshes
StorageSeparate etcd instances
Control PlaneDedicated API servers

No shared components between customer clusters.


Supply Chain Security

Image Verification

All images must be signed:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sVerifiedImage
metadata:
  name: verify-image-signatures
spec:
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
  parameters:
    allowedRepos:
    - ghcr.io/tasmanian-cloud/*
    - registry.tasmanian.cloud/*
    requiredSignature:
    - issuer: "https://token.actions.githubusercontent.com"
      subject: "https://github.com/tasmanian-cloud/*"

SBOM and Vulnerability Scanning

StageToolAction on Failure
BuildSyft (SBOM), Grype (scan)Block image push
AdmissionTrivy OperatorReject vulnerable pods
RuntimeFalcoAlert on anomalous behavior

GitOps Security

FluxCD configurations are validated:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: app
  namespace: flux-system
spec:
  interval: 10m
  path: ./clusters/production
  prune: true
  sourceRef:
    kind: GitRepository
    name: app
  validation: server  # Validate against API server
  healthChecks:
  - apiVersion: apps/v1
    kind: Deployment
    name: app
    namespace: production

Audit Logging

All API requests are logged:

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/default/pods",
  "verb": "create",
  "user": {
    "username": "developer@tasmanian.cloud",
    "groups": ["system:authenticated"]
  },
  "sourceIPs": ["10.0.40.15"],
  "userAgent": "kubectl/v1.29.0",
  "objectRef": {
    "resource": "pods",
    "namespace": "default",
    "name": "nginx"
  },
  "responseStatus": {
    "code": 201
  },
  "requestObject": { /* ... */ },
  "responseObject": { /* ... */ }
}

Logs are shipped to Wazuh SIEM in real-time.


Security Controls Summary

ControlImplementationVerification
OS hardeningTalos Linux (immutable)Automated compliance
Pod securityPod Security Standards (Restricted)OPA/Gatekeeper
Network securityCilium eBPF policiesConnectivity tests
Runtime securityTetragonThreat detection rules
Image securityCosign signatures, Trivy scansAdmission control
Secret encryptionKMS + etcd encryptionKey rotation audit
RBACLeast privilege, regular reviewAccess audits
Audit loggingKubernetes audit + FalcoSIEM integration