Container and Kubernetes security

The Helm charts support hardened runtime containers while preserving existing tag, Secret and service-account configuration. Test the settings with your own extensions, admission policies and storage before upgrading a production release.

Runtime identity and writable storage

Chart-managed containers retain UID/GID 899, non-root execution, dropped Linux capabilities and disabled privilege escalation. The default security context also uses readOnlyRootFilesystem: true and seccompProfile.type: RuntimeDefault. Images retain the .NET chiseled runtime and globalization support; the image's default user and a Kubernetes runAsUser override are distinct settings.

The AdminApp resource-deployment Job writes its CLI configuration to /tmp/.proauthcli. Data Protection also creates temporary files while protecting the CLI token, so the Job defaults TMPDIR to that same directory. The chart provides a bounded emptyDir only there, with resourceJobStorage.sizeLimit: 16Mi and resourceJobStorage.fsGroup: 899. Match the group to a custom Job identity if you override it. An explicit TMPDIR supplied by the resource-deployment Secret takes precedence and must refer to writable storage you provide. The Core application and migration Job do not receive a general writable /tmp mount.

You can override securityContext and per-init-container security contexts. If an extension requires writing files, identify the exact directory and provision an appropriate bounded volume rather than making the whole filesystem writable. Do not store durable application data in an emptyDir.

Kubernetes API tokens and service accounts

kubernetesApiAccess.mode: selective disables automatic Kubernetes API-token mounting on the Pod. The chart projects a short-lived API token, CA certificate and namespace into init containers at the standard service-account directory. Existing wait-for containers continue to observe migration/resource Jobs and Pods with the same service account and RBAC.

Custom init containers retain API access unless explicitly configured with kubernetesApiAccess: false. Containers that do not use the Kubernetes API should opt out:

initContainers:
  - name: custom-preparation
    image: example/preparation
    tag: '1.0'
    kubernetesApiAccess: false

The main application does not mount this token by default. Set kubernetesApiAccess.application: true if your application or extension needs it. kubernetesApiAccess.mode: legacy preserves Kubernetes' automatic mounting behavior for integrations that depend on it. Azure workload-identity tokens use a separate audience and webhook-controlled projection; they are not replaced with Kubernetes API tokens or database passwords. With kubernetesApiAccess.dapr: true (the default), the chart uses Dapr's dapr.io/volume-mounts annotation to mount the projected API token read-only in an enabled sidecar, preserving Kubernetes secret-store/component access and existing custom sidecar mounts. Set it to false only when those components do not require API access, and disable the built-in Kubernetes secret store as appropriate. The application still receives no API token. Validate injection with your installed Dapr version; see Dapr volume-mount configuration.

Precreated service accounts and existing chart RBAC settings remain supported. These changes do not require additional Kubernetes RBAC permissions. Customers remain responsible for permissions on accounts they manage themselves.

Migration Jobs, probes and resources

Completed migration and resource-deployment Jobs are intentionally retained. Application init containers rely on their successful status. Do not enable a TTL controller or manually delete these Jobs while the corresponding release still depends on them.

deploymentJob.backoffLimit defaults to 1; deploymentJob.activeDeadlineSeconds defaults to 1800 and can be increased or set to 0 to omit the deadline. Set your Helm deployment timeout longer than the Job deadline plus application startup time. Database rollback and Helm rollback are different operations: retain your established database compatibility and backup procedure.

Probe paths/timing are configurable under probes.liveness, probes.readiness and probes.startup. The Core readiness/startup endpoints remain distinct. AdminApp uses its existing /health endpoint. terminationGracePeriodSeconds defaults to 30. Existing resources, deploymentJobResources, replica, topology and other workload-specific values remain configurable; choose requests/limits from measured workload usage.

Network and admission policies

The charts do not enable namespace Pod Security Admission enforcement or replace customer admission policies. networkPolicy.enabled defaults to false. Customers can continue to manage NetworkPolicies externally.

If you opt in, configure networkPolicy.policyTypes, networkPolicy.ingress and networkPolicy.egress for your environment. The policy selects this chart's release, including its Jobs. Empty ingress/egress lists with both policy types enabled deny traffic. Explicitly allow the required DNS, ingress-controller, database, Kubernetes API for wait-for containers, telemetry, Dapr and cloud-identity/service endpoints. NetworkPolicy enforcement requires a compatible cluster network plug-in; standard NetworkPolicy rules do not resolve arbitrary DNS names.

Secrets

Both existing mechanisms remain supported: inline Helm configuration and precreated Secrets referenced through externalSecrets/certificateSecrets. Prefer precreated Secrets or your organization's external-secret controller. Inline values can be retained in Helm release history, even when Kubernetes Secret resources are subsequently rotated. Restrict access to release metadata and follow your existing rotation procedure.

See Helm configuration for existing Secret keys and account options. No new external-secret operator is required.

Immutable images and private mirrors

Published digest-aware charts use a release digest map keyed by the exact repository:tag. An explicit image.digest takes precedence. An overridden tag or repository not present in that map retains tag-based behavior, so existing customer overrides continue to work.

For a private mirror, retain digest selection explicitly:

image:
  repository: mirror.example/proauthcore
  digest: sha256:<64-lowercase-hex-digits>
  dbdeployclirepository: mirror.example/proauthcoredbmigrationcli
  dbdeployclidigest: sha256:<migration-image-digest>
  dbdeployworkerrepository: mirror.example/proauthcoredbdeploymentuserstoreworker
  dbdeployworkerdigest: sha256:<worker-image-digest>

AdminApp uses image.digest and image.resourcesdeployclidigest. An init container can specify its own digest. Use the actual digest supplied with the release, not the illustrative placeholders above. To continue using a tag, leave the corresponding explicit digest empty and set the desired tag. If intentionally using the packaged default tag without its digest, also clear that repository/tag entry from image.releaseDigests.

Signature verification

Publisher pipelines use Notation with a non-exportable Azure Key Vault signing key. Customer admission enforcement remains optional; the charts do not install a signature-policy controller or require access to the publisher's Key Vault.

Obtain the publisher's public trust certificate and independently verify its fingerprint through your release/support channel. Configure Notation with that certificate and the exact identity x509.subject: CN=ProAuth Container Signing,O=4tecture GmbH,ST=Zurich,C=CH, a repository-specific scope and signatureVerification.level: strict. Do not trust an arbitrary certificate supplied alongside an untrusted image or use a wildcard signing identity.

Mirrors must copy signatures and related OCI artifacts, not only image layers. With an authenticated ORAS client supporting recursive copy:

oras cp --recursive "$SOURCE_REPOSITORY@$DIGEST" "$MIRROR_REPOSITORY:$TAG"
test "$(oras resolve "$MIRROR_REPOSITORY:$TAG")" = "$DIGEST"
notation verify "$MIRROR_REPOSITORY@$DIGEST"

Configure the local Notation policy for the mirror repository while retaining the publisher's certificate and signing identity. Keep the same image bytes/digest. A mirror that rewrites or rebuilds images creates a different artifact and cannot reuse the original signature. Validate your registry's referrer support and certificate-expiry/rotation procedure before enforcing verification on upgrades or rollbacks.

Refer to Microsoft's Notation guidance for trust-policy setup. Existing Azure Docker Content Trust is a separate legacy mechanism and is not automatically disabled by these chart changes.