Skip to content

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 🤖

Merge request reports