Files
helm-charts/rallly/values.yaml
jklein fe6839265c rallly: seccompProfile RuntimeDefault in the pod context
Sets seccompProfile.type: RuntimeDefault in the pod security context, so
the container runtime's default syscall filter applies to every container
in the pod.

The value lives in the pod context rather than the container context
because it covers init containers and any container added later without
being repeated; a container that needs a different filter can still
override it under securityContext.container, which wins over the pod
value.

Verified in k3d against the database path rather than a static page:
under the filter the app opens its connection to Postgres and Prisma
applies all migrations (141 rows in _prisma_migrations, 31 tables
created), and the server-rendered pages answer with HTTP 200. The kernel
reports Seccomp: 2 (filter mode) inside the container.

Major bump: runtime behavior changes.

Refs #84
2026-08-23 23:37:42 +02:00

135 lines
5.4 KiB
YAML

# Scale the whole chart down without uninstalling it: scaleDown: true renders
# every Deployment/StatefulSet with replicas: 0 (and suspends CronJobs) and
# takes precedence over any per-workload replicas value. PVCs, Secrets and
# Services stay in place; scaleDown: false brings the workloads back up.
scaleDown: false
secrets:
ralllySecretRef: null
oidcSecretRef: null
databaseSecretRef: null
smtpSecretRef: null
rallly:
# Replica count for this workload; 0 is allowed and scales it down.
# The chart-global scaleDown flag takes precedence.
replicas: 1
smtp:
enabled: false
# Verify the mail server's TLS certificate (passed to the app as
# SMTP_REJECT_UNAUTHORIZED). Leave this at true.
#
# Set it to false ONLY for a mail server with a self-signed certificate.
# Without that hint the symptom is misleading: the send fails with a
# certificate error naming the mail server, so the search starts at the
# mail server or its CA chain rather than at this value.
#
# false disables the certificate check entirely and exposes the SMTP
# session to a man-in-the-middle; prefer trusting the CA over setting it.
rejectUnauthorized: true
allowedEmails: '*'
supportEmail: null
oidc:
name: 'OIDC'
pictureClaimPath: 'picture'
emailClaimPath: 'email'
nameClaimPath: 'name'
# Next.js writes its cache below the app directory (prerendered/ISR pages and
# the optimized images of /_next/image). The container runs as uid 20000
# while /app belongs to the image's own "nextjs" user, so that path is not
# writable for the app even without readOnlyRootFilesystem — the chart mounts
# a writable volume over it. The pod's fsGroup (1000) is what makes the
# mounted volume group-writable for the container.
#
# Deliberately an emptyDir, not a PVC: the cache is volatile. After every pod
# restart it starts out empty and Next.js rebuilds it on demand, which costs
# a little time on the first request after a restart. That is correct for a
# cache — its entries are derived data tied to the build id of the image, so
# a persistent volume would only carry stale entries across app updates.
cache:
# Mount path of the cache volume. Matches the Next.js cache directory of
# the upstream image; only needs changing if the image layout changes.
path: /app/apps/web/.next/cache
# Optional upper bound for the emptyDir, e.g. 512Mi. Unset means the volume
# is only bounded by the container's ephemeral-storage limit (computed as
# limitFactor x request, see resources below) — note that emptyDir usage
# counts against that limit, and exceeding either bound evicts the pod.
sizeLimit: null
securityContext:
pod:
runAsNonRoot: true
runAsUser: 20000
runAsGroup: 1000
fsGroup: 1000
fsGroupChangePolicy: Always
# RuntimeDefault applies the container runtime's default seccomp filter,
# which blocks the syscalls a normal workload never makes. It sits in the
# pod context on purpose: from here it covers every container in the pod
# including init containers, while a container-level seccompProfile would
# have to be repeated for each one (and silently missed on the next one
# added). A container that genuinely needs a different filter can still
# override it under securityContext.container, which wins over this value.
seccompProfile:
type: RuntimeDefault
container:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsNonRoot: true
# No capabilities are added: the app is a plain Node process listening on
# the unprivileged port 3000, verified to run with all capabilities
# dropped. Do not reintroduce an "add:" key here — an empty list item
# under it renders as a null entry, which is what Trivy reported as
# AVD-KSV-0022 for the older chart version deployed in the cluster (#84).
capabilities:
drop:
- ALL
# Extra environment variables, appended to the ones the chart always sets.
# Values are rendered through tpl; value, secretKeyRef and configMapKeyRef
# forms are supported.
env: []
resources:
# Limits are optional: memory and ephemeral-storage limits default to
# limitFactor x the request, an explicitly set limit always wins, and a
# CPU limit is only set when configured explicitly under "limits".
limitFactor: 3
requests:
cpu: 0.1
memory: 512Mi
ephemeral-storage: 100Mi
livenessProbe:
httpGet:
path: /
port: http
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /
port: http
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
# The startup probe gates liveness/readiness, so those need no initialDelaySeconds.
# Startup budget = periodSeconds * failureThreshold = 150s.
startupProbe:
httpGet:
path: /
port: http
periodSeconds: 5
timeoutSeconds: 5
failureThreshold: 30
ingress:
# Set to false to omit the Ingress entirely. Note that ingress.domain stays
# required even then: it is also the app's public base URL
# (NEXT_PUBLIC_BASE_URL), not just the Ingress host. Only clusterIssuer
# becomes unnecessary.
enabled: true
clusterIssuer: null
domain: null
className: nginx
# Extra annotations for the Ingress; merged with the cert-manager
# cluster-issuer annotation the chart always sets.
annotations: {}