search

Oteemo / charts

Helm chart repository
https://oteemo.github.io/charts
MIT License
180 stars 231 forks source link

[sonarqube] securityContext.runAsUser applies to all containers, not just sonarqube, meaning that I cannot deploy the chart #56

Open VioletHynes opened 4 years ago

VioletHynes commented 4 years ago

Currently, I have an issue with deploying this chart that I'm not sure how to resolve. If I use the following values:

# Set security context for sonarqube pod
securityContext:
  fsGroup: 999
  runAsUser: 999

Then it fails to run chmod-volume-mounts:

[ahynes@mt02c1kub0001p charts]$ kubectl logs pod/sonarqube-sonarqube-9b8dc9795-gk7dg -c chmod-volume-mounts
mkdir: can't create directory '/opt/sonarqube/certs': Permission denied

If I use the following, instead:

# Set security context for sonarqube pod
securityContext:
  fsGroup: 999
  # runAsUser: 999

Then chmod-volume-mounts runs fine, but sonarqube fails to start as ElasticSearch cannot be ran as root. Ideally, I'd be able to run chmod-volume-mounts as root, and sonarqube as the service account.

Given this information, I'm not sure how anybody has got this chart running, so maybe I'm just doing something wrong? I am using persistence.enabled = true, if that counts for anything. Looking for advice/a fix.

Results of kubectl version here:

[ahynes@mt02c1kub0001p charts]$ kubectl version
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.2", GitCommit:"66049e3b21efe110454d67df4fa62b08ea79a19b", GitTreeState:"clean", BuildDate:"2019-05-16T16:23:09Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.2", GitCommit:"66049e3b21efe110454d67df4fa62b08ea79a19b", GitTreeState:"clean", BuildDate:"2019-05-16T16:14:56Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
VioletHynes commented 4 years ago

Is this a bug or am I missing something dumb here? I don't see how you can deploy this chart as-is.

namloc2001 commented 4 years ago

@AndrewHynes This might be resolved now via this (in values.yaml):

# Set security context for sonarqube pod
securityContext:
  fsGroup: 1000

# Set security context for sonarqube container
containerSecurityContext:
  # Sonarqube dockerfile creates sonarqube user as UID and GID 1000
  runAsUser: 1000

initContainers:
  # We allow the init containers to have a separate security context declaration because
  # the initContainer may not require the same as SonarQube.
  # securityContext: {}

initSysctl:
  securityContext:
    privileged: true

Please see if this resolves your issue.