Add SeccompProfile support to container SecurityContext
-
Please check this box if this contribution uses AI-generated content as outlined in the GitLab DCO & CLA
What does this MR do?
Adds the ability to specify the seccompProfile:
example:
...
spec:
securityContext:
seccompProfile:
type: RuntimeDefault
...
On Kubernetes Container Security Context to restrict a container's syscalls. Some companies enforce that this be present on the resources in the cluster.
Why was this MR needed?
Allows easier definition that the alternative which is to enable FF_USE_ADVANCED_POD_SPEC_CONFIGURATION and then have to do patching as follows:
...
[[runners.kubernetes.pod_spec]]
name = "update_init_container_security_context"
patch_type = "strategic"
patch = '''
initContainers:
- name: init-permissions
seccompProfile:
type: RuntimeDefault
'''
[[runners.kubernetes.pod_spec]]
name = "update_build_container_security_context"
patch_type = "strategic"
patch = '''
containers:
- name: build
seccompProfile:
type: RuntimeDefault
'''
[[runners.kubernetes.pod_spec]]
name = "update_helper_container_security_context"
patch_type = "strategic"
patch = '''
containers:
- name: helper
seccompProfile:
type: RuntimeDefault
'''
...
Also makes these settings available for use with environment variables so no need to patch the config.toml.
What's the best way to test this MR?
Create a runner that uses the Kubernetes executor and defines the configuration of the security context with the added fields.
What are the relevant issue numbers?
Closes #36290
Edited by 🤖 GitLab Bot 🤖