Skip to content

securityContext support for namespaces with pod-security.kubernetes.io/enforce: restricted

André Frimberger requested to merge afrimberger/gitlab:feature/enforce-restricted into master
  • Please check this box if this contribution uses AI-generated content (including content generated by GitLab Duo features) as outlined in the GitLab DCO & CLA

What does this MR do?

This MR adds the necessary securityContext and podSecurityContext configuration for deploying Gitlab in namespaces with pod-security.kubernetes.io/enforce: restricted

To follow the "security by default" pattern, the security context settings are set by default in the corresponding Helm Charts and can be optionally changed by an end user.

Used values file for testing the deployment:

upgradeCheck:
  enabled: false # needed on first installation via ArgoCD https://gitlab.com/gitlab-org/charts/gitlab/-/issues/4661, https://github.com/argoproj/argo-cd/issues/7536

global:
  gitlabVersion: "16.11.1" # remove after installation is stable
  edition: ce
  hosts:
    domain: k8s.my.domain.de
    externalIP: "10.0.0.49"
  ingress:
    enabled: true
  pages:
    accessControl: true
    enabled: true
  praefect:
    enabled: false
    replaceInternalGitaly: false

postgresql:
  image:
    tag: 16.2.0
nginx-ingress:
  enabled: true
  defaultBackend:
    enabled: true
gitlab:
  sidekiq:
    resources:
      requests:
        cpu: 100m

certmanager-issuer:
  email: andre@my.domain.de

certmanager:
  install: false
  installCRDs: false
gitlab-runner:
  install: true
prometheus:
  install: true

%{first_multiline_commit}

Related issues

Author checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

  • Merge Request Title and Description are up to date, accurate, and descriptive
  • MR targeting the appropriate branch
  • MR has a green pipeline on GitLab.com
  • When ready for review, follow the instructions in the "Reviewer Roulette" section of the Danger Bot MR comment, as per the Distribution experimental MR workflow

For merge requests from forks, consider the following options for Danger to work properly:

Expected (please provide an explanation if not completing)

  • Test plan indicating conditions for success has been posted and passes
  • Documentation created/updated
  • Tests added/updated
  • Integration tests added to GitLab QA
  • Equivalent MR/issue for omnibus-gitlab opened
  • Equivalent MR/issue for Gitlab Operator project opened (see Operator documentation on impact of Charts changes)
  • Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme://user:passwd@host:port may require quotation or other special handling when rendered in a template and written to a configuration file.
Edited by André Frimberger

Merge request reports