[jira] [Updated] (FLINK-28554) Kubernetes-Operator allow readOnlyRootFilesystem via operatorSecurityContext
[ https://issues.apache.org/jira/browse/FLINK-28554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated FLINK-28554: --- Labels: operator pull-request-available (was: operator) > 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, pull-request-available > > 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)
[jira] [Updated] (FLINK-28554) Kubernetes-Operator allow readOnlyRootFilesystem via operatorSecurityContext
[ https://issues.apache.org/jira/browse/FLINK-28554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim updated FLINK-28554: Description: 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? was: 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/commit/98c30d22ed998c7eccb66875de8884a701079412|https://github.com/apache/flink-kubernetes-operator/commit/98c30d22ed998c7eccb66875de8884a701079412)]) 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? > 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 >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 > fo
[jira] [Updated] (FLINK-28554) Kubernetes-Operator allow readOnlyRootFilesystem via operatorSecurityContext
[ https://issues.apache.org/jira/browse/FLINK-28554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim updated FLINK-28554: Summary: Kubernetes-Operator allow readOnlyRootFilesystem via operatorSecurityContext (was: Kubernetes-Operator allow readOnlyRootFilesystem via securityContext) > 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 >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/commit/98c30d22ed998c7eccb66875de8884a701079412|https://github.com/apache/flink-kubernetes-operator/commit/98c30d22ed998c7eccb66875de8884a701079412)]) > 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 thought about yet? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FLINK-28554) Kubernetes-Operator allow readOnlyRootFilesystem via operatorSecurityContext
[ https://issues.apache.org/jira/browse/FLINK-28554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim updated FLINK-28554: Description: 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/commit/98c30d22ed998c7eccb66875de8884a701079412|https://github.com/apache/flink-kubernetes-operator/commit/98c30d22ed998c7eccb66875de8884a701079412)]) 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? was: 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/commit/98c30d22ed998c7eccb66875de8884a701079412|https://github.com/apache/flink-kubernetes-operator/commit/98c30d22ed998c7eccb66875de8884a701079412)]) 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 thought about yet? > 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 >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/commit/98c30d22ed998c7eccb66875de8884a701079412|https://github.com/apache/flink-kubernetes-operator/commit/98c30d22ed998c7ecc