Skip to content

Security

Security is applied at every layer of the deployment — from Azure RBAC controlling cluster access, through AKS deployment safeguards enforcing pod compliance, to Istio mTLS encrypting all service-to-service traffic.

AKS Deployment Safeguards

AKS Automatic enforces Gatekeeper policies at admission. All Helm charts must produce compliant manifests. The shared Kustomize postrender framework in software/stack/kustomize/ patches charts to add:

  • Health probes (readiness/liveness) with appropriate initialDelaySeconds
  • Resource requests and limits
  • Seccomp profiles (RuntimeDefault)
  • Security context hardening (runAsNonRoot, drop ALL capabilities)
  • Unique service selectors

See ADR-0004 for the postrender approach and Service Architecture for the pipeline details.

Safeguards gate

Azure Policy/Gatekeeper is eventually consistent. The post-provision hook includes a safeguards readiness gate that validates policy convergence via server-side dry-run before any workloads deploy (see ADR-0007).

Istio mTLS

AKS-managed Istio (revision asm-1-28) provides mutual TLS encryption for all east-west traffic within the service mesh.

Namespace Configuration

Namespace Istio Injection mTLS Mode Policy
platform Enabled STRICT PeerAuthentication per namespace
osdu Enabled STRICT PeerAuthentication per namespace
foundation N/A N/A Operators — no mesh participation

Both namespaces are labeled with istio-injection: enabled, and a STRICT PeerAuthentication resource enforces mTLS for all service-to-service communication.

Selective Sidecar Injection

Specific pods that require NET_ADMIN capabilities or have incompatible networking opt out at the pod level (see ADR-0009):

Component Injection Reason
OSDU services Enabled Full mesh participation
Middleware (default) Enabled Cross-namespace mTLS
RabbitMQ Disabled Clustering requires NET_ADMIN
CNPG Jobs Disabled Short-lived initdb/join Jobs

Opt-out is done via pod annotation:

metadata:
  annotations:
    sidecar.istio.io/inject: "false"

Pods that opt out of the mesh rely on application-layer security (password authentication) instead of mTLS.

Additional Transport Encryption

Elasticsearch uses ECK self-signed TLS for transport-layer encryption between nodes, in addition to Istio mTLS on the sidecar level (see ADR-0008).

Pod Security

All workloads comply with AKS deployment safeguards. The Kustomize postrender enforces these constraints on every Helm release:

Constraint Value Purpose
runAsNonRoot true Prevent root container execution
allowPrivilegeEscalation false Block setuid/setgid binaries
Seccomp profile RuntimeDefault Restrict system calls
Capabilities drop: ["ALL"] Remove all Linux capabilities
Image tags No :latest Pin to specific versions

Forbidden capabilities

NET_ADMIN and NET_RAW capabilities are blocked by AKS safeguards. Components that require them (RabbitMQ) opt out of Istio injection instead.

Azure RBAC

Kubernetes Authentication

  • Local accounts disabled; Azure AD authentication required
  • Core infrastructure does not assign AKS access implicitly to the current deployer
  • AKS bootstrap access is granted later through infra-access/ to explicit user or group object IDs
  • Azure RBAC roles commonly used for bootstrap:
Role Scope Purpose
Azure Kubernetes Service RBAC Cluster Admin AKS cluster Full cluster access for bootstrap
Azure Kubernetes Service RBAC Admin AKS cluster Namespace-scoped admin
Azure Kubernetes Service RBAC Reader AKS cluster Read-only monitoring

Workload Identity

Workload Identity enables pods to authenticate to Azure services without storing credentials (see ADR-0010):

Pod → Service Account → Federated Credential → Azure AD → Azure Resource

Used by ExternalDNS for cross-subscription DNS zone management. The managed identity is created in infra/, the federated credential is linked in infra-access/, and the DNS role assignment grants zone read/write access.

Authentication Flows

User Authentication (Azure AD → Kubernetes)

Step Action
1 User authenticates via az login
2 Azure AD issues tokens
3 kubelogin exchanges Azure AD token for Kubernetes API access
4 AKS RBAC evaluates role assignments

OSDU Service Authentication (Keycloak)

Step Action
1 Client requests token from Keycloak (osdu realm)
2 Keycloak validates credentials and issues JWT
3 Client sends JWT in Authorization header to OSDU service
4 OSDU service validates JWT signature and claims
5 Entitlements service checks group membership for authorization

The datafier client in the Keycloak osdu realm is a confidential service account used by bootstrap containers to provision initial data (entitlements groups, partition registration).

See also