[
https://issues.apache.org/jira/browse/FLINK-28554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Wang reassigned FLINK-28554:
---------------------------------
Assignee: Tim
> Kubernetes-Operator allow readOnlyRootFilesystem via operatorSecurityContext
> ----------------------------------------------------------------------------
>
> Key: FLINK-28554
> URL: https://issues.apache.org/jira/browse/FLINK-28554
> Project: Flink
> Issue Type: Improvement
> Components: Kubernetes Operator
> Affects Versions: kubernetes-operator-1.0.1
> Reporter: Tim
> Assignee: Tim
> Priority: Minor
> Labels: operator
>
> It would be nice if the operator would support using the
> "readOnlyRootFilesystem" setting via the operatorSecurityContext. When using
> the default operator template the operator won't be able to start when using
> this setting because the config files mounted in `/opt/flink/conf` are now
> (of course) also read-only.
> It would be nice if the default template would be written in such a way that
> it allows adding emptyDir volumes to /opt/flink/conf via the values.yaml.
> Which is not possible right now. Then the config files can remain editable by
> the operator while keeping the root filesystem read-only.
> I have successfully tried that in my branch (see:
> https://github.com/apache/flink-kubernetes-operator/compare/main...timsn:flink-kubernetes-operator:mount-single-flink-conf-files)
> which prepares the operator template.
> After this small change to the template it is possible add emptyDir volumes
> for the conf and tmp dirs and in the second step to enable the
> readOnlyRootFilesystem setting via the values.yaml
> values.yaml
> {code:java}
> [...]
> operatorVolumeMounts:
> create: true
> data:
> - name: flink-conf
> mountPath: /opt/flink/conf
> subPath: conf
> - name: flink-tmp
> mountPath: /tmp
> operatorVolumes:
> create: true
> data:
> - name: flink-conf
> emptyDir: {}
> - name: flink-tmp
> emptyDir: {}
> operatorSecurityContext:
> readOnlyRootFilesystem: true
> [...]{code}
> I think this could be a viable way to allow this security setting and I could
> turn this into a pull request if desired. What do you think about it? Or is
> there even a better way to achive this I didn't think about yet?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
