Looks like a simple FF removal, approving. @pshutsin could you give this a database maintainer review?

Summary

Remove the show_child_security_reports_in_mr_widget feature flag to permanently enable displaying security scan results from child pipelines in the merge request security widget.

This has been enabled in production for a month now; and additionally enabled on SM

What does this MR do?

With this change:

• SAST, secret detection, and container scanning reports from child pipelines are now shown in the MR security widget
• The pipeline security tab displays vulnerabilities from the entire pipeline hierarchy
• Security findings finder includes results from child pipelines

Changes

• Removes the feature flag YAML definition
• Removes all feature flag conditionals from application code
• Removes feature flag disabled test contexts from specs
• Updates documentation to remove feature flag mentions

Related issues

Closes #586210

Hi @rettelbachj

Thanks for your contribution. It looks good to me, but it seems similar to discussion happening in another similar MR. It seems that the approach that you found is more preferrable as it avoids explicitly exposing every possible kubernetes config through runner.

@ratchade @avonbertoldi could you chime in on this?

Sam Roque-Worcel (13ccd525) at 19 Mar 03:04

... and 1464 more commits

Hi @marcogreg, could you give this a backend maintainer review?? Thanks!

Hi @MarcUllman

Thanks for that. The new code looks good! I'll approve. Thanks for working on this.

@avonbertoldi could you give this a maintainer review?

Feature Request: Add SeccompProfile and AppArmorProfile to Kubernetes executor security context configuration

Summary

Add native seccomp_profile_type and app_armor_profile_type fields (with corresponding localhost_profile fields) to [runners.kubernetes.build_container_security_context] and the pod/helper/service/init security context sections in config.toml, so users can configure Seccomp and AppArmor profiles without relying on deprecated annotations or pod spec patches.

Motivation

The Kubernetes executor currently lacks native support for configuring seccomp profiles and AppArmor profiles through the security context configuration. Users who need these settings face three problematic workarounds:

1. Deprecated annotations — container.seccomp.security.alpha.kubernetes.io/build = "unconfined" was removed in Kubernetes 1.27. The AppArmor annotation still works but is deprecated in favor of the securityContext.appArmorProfile field (GA in K8s 1.30).
2. Pod spec patches — Require the beta FF_USE_ADVANCED_POD_SPEC_CONFIGURATION feature flag, embed JSON/YAML inside TOML, don't integrate with Helm charts, and lack validation. Prior to Runner 18.7.0, patches were silently dropped because the k8s client-go (v0.26) did not include the AppArmorProfile type.
3. No coverage for all container types — Neither annotations nor pod spec patches reliably configure the helper container.

Real-world impact: Ubuntu 23.10+ enables kernel.apparmor_restrict_unprivileged_userns=1 by default, which blocks rootless container image building tools (BuildKit, Podman) from mounting /proc inside RUN steps. The only fix is setting appArmorProfile: { type: Unconfined } on the build container — which is impossible through config.toml today.

This also blocks compliance-driven environments (e.g., Azure AKS policy enforcement) that require explicit seccomp profiles on all pods.

Related Issues

• #26849 — Allow setting seccomp policy in security context in config.toml
• #38936 — Add ability to configure AppArmor for build pod Security Context
• #38266 — Unable to configure AppArmor profile for build pods when using Kubernetes executor

Proposal

Add four new fields to both KubernetesContainerSecurityContext and KubernetesPodSecurityContext config structs:

[runners.kubernetes.build_container_security_context]
  seccomp_profile_type = "Unconfined"                    # RuntimeDefault | Localhost | Unconfined
  seccomp_profile_localhost_profile = ""                  # required when type = Localhost
  app_armor_profile_type = "Unconfined"                   # RuntimeDefault | Localhost | Unconfined
  app_armor_profile_localhost_profile = ""                # required when type = Localhost

[runners.kubernetes.pod_security_context]
  seccomp_profile_type = "RuntimeDefault"
  seccomp_profile_localhost_profile = ""
  app_armor_profile_type = "RuntimeDefault"
  app_armor_profile_localhost_profile = ""

Behavior:

• When seccomp_profile_type is set, construct api.SeccompProfile{Type: ...} on the returned SecurityContext
• When app_armor_profile_type is set, construct api.AppArmorProfile{Type: ...} on the returned SecurityContext
• When type is Localhost, require the corresponding localhost_profile field; log a warning and skip if missing
• When type is empty, omit the field entirely (unchanged from today)
• Container-level overrides pod-level (standard Kubernetes precedence)
• Invalid type values produce a warning log and are ignored

Affected Files

Config struct (common/config.go):

• KubernetesContainerSecurityContext — add 4 fields with TOML/JSON/env tags
• KubernetesPodSecurityContext — add 4 fields with TOML/JSON/env tags

Conversion logic (common/config.go):

• GetContainerSecurityContext() — set SeccompProfile and AppArmorProfile on returned api.SecurityContext
• GetPodSecurityContext() — set SeccompProfile and AppArmorProfile on returned api.PodSecurityContext
• Add helper functions toSeccompProfile() and toAppArmorProfile() for validation and conversion

Documentation (docs/executors/kubernetes/index.md or equivalent):

• Add seccomp_profile_type, seccomp_profile_localhost_profile, app_armor_profile_type, app_armor_profile_localhost_profile to the container security context options table
• Add same fields to the pod security context options table
• Document minimum Kubernetes version requirement: seccomp requires K8s >= 1.19, AppArmor field requires K8s >= 1.30

Example Usage

Rootless BuildKit image building on Ubuntu 23.10+ nodes:

[[runners]]
  executor = "kubernetes"
  [runners.kubernetes]
    [runners.kubernetes.build_container_security_context]
      app_armor_profile_type = "Unconfined"
      seccomp_profile_type = "Unconfined"

Azure AKS compliance with RuntimeDefault seccomp:

[[runners]]
  executor = "kubernetes"
  [runners.kubernetes]
    [runners.kubernetes.pod_security_context]
      seccomp_profile_type = "RuntimeDefault"

Custom seccomp profile:

[[runners]]
  executor = "kubernetes"
  [runners.kubernetes]
    [runners.kubernetes.build_container_security_context]
      seccomp_profile_type = "Localhost"
      seccomp_profile_localhost_profile = "profiles/my-profile.json"

Tests

Add test cases to existing security context test files following the project's Ginkgo/Gomega patterns:

1. Seccomp profile type set to Unconfined — verify api.SecurityContext.SeccompProfile.Type is api.SeccompProfileTypeUnconfined
2. Seccomp profile type set to Localhost with localhost_profile — verify both Type and LocalhostProfile are set
3. Seccomp profile type set to Localhost without localhost_profile — verify warning logged and field omitted
4. AppArmor profile type set to Unconfined — verify api.SecurityContext.AppArmorProfile.Type is api.AppArmorProfileTypeUnconfined
5. AppArmor profile type set to Localhost with localhost_profile — verify both fields set
6. Invalid profile type — verify warning logged and field omitted
7. Pod-level security context — same tests at pod level
8. Container-level overrides pod-level — verify container settings take precedence

Changelog

Changelog: added

Kubernetes executor: Add seccomp and AppArmor profile configuration to container and pod security contexts

Additional Context

• The k8s client-go was updated to v0.32.10 in Runner v18.7.0 (!5929 (merged)), so the api.AppArmorProfile type is now available in the codebase.
• The AppArmorProfile field in SecurityContext is GA since Kubernetes 1.30. Setting it against older apiservers may cause pod creation to fail. This should be documented as a minimum version requirement.
• For backward compatibility with clusters < 1.30, a future enhancement could add automatic fallback to legacy AppArmor annotations, but this is out of scope for the initial implementation.
• The existing ProcMount and SELinuxType fields follow the same pattern of string-typed config values converted to k8s API types, so this change is consistent with existing conventions.

What does this MR do and why?

References

Screenshots or screen recordings

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #588510

Sam Roque-Worcel (c86958be) at 17 Mar 00:25

@gitlab-bot retry_pipeline 2388462751

I've kicked of a full pipeline for you as well. Do you mind taking a look at those failures and letting me know if they're just flakes?

Theres a bit of duplication between these two methods, can we avoid that and try and consolidate the code?

Hi @MarcUllman

Sorry about the delay. Overall the MR looks OK and the change seems safe enough, as it adds options for a new feature that we're keen to support.

I've left a couple of comments regarding the style of the code, and will review the tests in more detail next time. Can you please test this code and make sure this works? A screenshot of this setting being enabled and reflected in the security context configuration would be perfect. More info on setup may be here Kubernetes executor | GitLab Docs