Summary
The kyma app push command creates Kubernetes Deployments without a solid baseline for security. The security context for "app pushed" workloads should be consistent across kyma prototyping capabilities to ensure uniform security posture.
Current Behavior
The buildSecurityContext function in internal/kube/resources/deployment.go applies the following security context when --insecure is not set:
PodSecurityContext:
RunAsUser: 1000
RunAsGroup: 3000
RunAsNonRoot: true
SeccompProfile: RuntimeDefault
AppArmorProfile: RuntimeDefault
Container SecurityContext:
Privileged: false
AllowPrivilegeEscalation: false
RunAsNonRoot: true
Capabilities.Drop: ["All"]
ReadOnlyRootFilesystem: true
Expected Behavior
The security context should match what the Kyma serverless controller applies to Function workloads (see buildless-serverless/internal/controller/resources/deployment.go):
PodSecurityContext:
RunAsUser: 1000
RunAsGroup: 1000 ← differs (currently 3000)
FSGroup: 1000 ← missing
SupplementalGroups: [1000] ← missing
SeccompProfile: RuntimeDefault
Container SecurityContext:
Privileged: false
AllowPrivilegeEscalation: false
RunAsNonRoot: true
Capabilities.Drop: ["ALL"]
ReadOnlyRootFilesystem: true
Changes Required
In internal/kube/resources/deployment.go, update buildSecurityContext to:
- Set
PodSecurityContext.RunAsGroup to 1000 (from 3000)
- Add
PodSecurityContext.FSGroup: 1000
- Add
PodSecurityContext.SupplementalGroups: [1000]
- Remove
AppArmorProfile (not set in serverless) — or confirm this is intentional and document the divergence
- Ensure
Capabilities.Drop uses "ALL" (uppercase, matching the serverless convention)
Motivation
Consistency between app push workloads and serverless Function workloads is important for:
- Uniform enforcement of the restricted Pod Security Standard
- Predictable behavior when both workload types coexist in the same namespace
- Simplified security auditing — one well-known security profile for all Kyma-managed workloads
References
Summary
The
kyma app pushcommand creates Kubernetes Deployments without a solid baseline for security. The security context for "app pushed" workloads should be consistent across kyma prototyping capabilities to ensure uniform security posture.Current Behavior
The
buildSecurityContextfunction ininternal/kube/resources/deployment.goapplies the following security context when--insecureis not set:PodSecurityContext:
RunAsUser: 1000RunAsGroup: 3000RunAsNonRoot: trueSeccompProfile: RuntimeDefaultAppArmorProfile: RuntimeDefaultContainer SecurityContext:
Privileged: falseAllowPrivilegeEscalation: falseRunAsNonRoot: trueCapabilities.Drop: ["All"]ReadOnlyRootFilesystem: trueExpected Behavior
The security context should match what the Kyma serverless controller applies to Function workloads (see
buildless-serverless/internal/controller/resources/deployment.go):PodSecurityContext:
RunAsUser: 1000RunAsGroup: 1000← differs (currently3000)FSGroup: 1000← missingSupplementalGroups: [1000]← missingSeccompProfile: RuntimeDefaultContainer SecurityContext:
Privileged: falseAllowPrivilegeEscalation: falseRunAsNonRoot: trueCapabilities.Drop: ["ALL"]ReadOnlyRootFilesystem: trueChanges Required
In
internal/kube/resources/deployment.go, updatebuildSecurityContextto:PodSecurityContext.RunAsGroupto1000(from3000)PodSecurityContext.FSGroup: 1000PodSecurityContext.SupplementalGroups: [1000]AppArmorProfile(not set in serverless) — or confirm this is intentional and document the divergenceCapabilities.Dropuses"ALL"(uppercase, matching the serverless convention)Motivation
Consistency between
app pushworkloads and serverless Function workloads is important for:References
app pushdeployment builder:internal/kube/resources/deployment.go