[grafana] Add DAC_READ_SEARCH to initChownData and readOnlyRootFilesystem

[jcpunk]

This should resolve the regression from #3684

[jkroepke]

@andreas-heatly are you able to test this to prevent an outage on your side?

[Kimi450]

I tested the restart usecase explained in #3699 and this fixes that at least

1. Install the chart
   helm upgrade -i my-release grafana/grafana --set initChownData.enabled=true --set persistence.enabled=true --wait
2. Once the pod is running, delete it
3. Observe that it cannot restart because the initcontainer fails with

chown: /var/lib/grafana/csv: Permission denied
chown: /var/lib/grafana/png: Permission denied
chown: /var/lib/grafana/pdf: Permission denied
19:52:16 dell-e7440 [--0] ~  $

4. updated the deployment with the changes proposed here
5. new pod comes up

[markussiebert]

Tested this - does not work with psp:

message: 'pods "grafana-64f4f78b5f-xkwr8" is forbidden: violates PodSecurity "baseline:latest":                               
      non-default capabilities (container "init-chown-data" must not include "DAC_READ_SEARCH"                                    
      in securityContext.capabilities.add)'

Don't think we have to give away more than the baseline policy?!

[jkroepke]

baseline policy

Generally, chown is a privileged operation. If you want to be compliant with baseline, just disable the initContainer. In modern Kubernetes environment, its generally not recommend to use that approach.

[jcpunk]

Breaking compat with baseline is not something I'm interested in.

There is some sort of strange interaction between the init-container and the pvc. I don't think I'll have time to look at this for a while... I'll close this PR out.

Interested folks at least have a hint something is tricky with the explicit readOnlyRootFilesystem: false.

[jkroepke]

Breaking compat with baseline is not something I'm interested in.

Sorry to interrupt here, but the chown init container will never be compatible with baseline.

Changing file owner is an operation done by the root account. This is normally done by securityContext.fsGroups. In production deployments, this initContainer not be not used.

But it's still valuable to increase the hardening in that context.

[markussiebert]

But I don't understand - shouldn't the default be the hardened? I am only here, because of the issues. Never decided to activate the init container. Never had any psp issues until the cap of this pr was added. And chown alone doesn't violate the psp.

[jkroepke]

But how the PSP can affect your deployment, if chmod container is not enabled on your deployment?

[markussiebert]

The default is enable chown

[jkroepke]

Thats the root issue. this should be not enabled by default.

[marquiz]

Looks like the formatting is incorrect

Suggested change

	| `initChownData.securityContext` | init-chown-data pod securityContext | `{"readOnlyRootFilesystem": true, "runAsNonRoot": false}`, "runAsUser": 0, "seccompProfile": {"type": "RuntimeDefault"}, "capabilities": {"add": ["CHOWN", "DAC_READ_SEARCH"], "drop": ["ALL"]}}` |
	| `initChownData.securityContext` | init-chown-data pod securityContext | `{"readOnlyRootFilesystem": true, "runAsNonRoot": false, "runAsUser": 0, "seccompProfile": {"type": "RuntimeDefault"}, "capabilities": {"add": ["CHOWN", "DAC_READ_SEARCH"], "drop": ["ALL"]}}` |

[jkroepke]

@marquiz are you interested into pick up this PR?