[ https://issues.apache.org/jira/browse/FLINK-30306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17679760#comment-17679760 ]
Alexis Sarda-Espinosa edited comment on FLINK-30306 at 1/23/23 11:04 AM: ------------------------------------------------------------------------- A few more thoughts from me. I'm not sure if it's feasible to cover all scenarios with redaction. Take for example the name of the (potentially internal) repository used in the resource's {{image}}, should that be redacted? Should redaction rules be configurable? For the scenario I initially reported, I did end up changing my resource to use {{valueFrom -> secretKeyRef}} since that covered my needs, but similar to the above, does that really cover all scenarios? Imagine someone wants to inject custom, sensitive values into the {{FlinkDeployment}}'s {{flinkConfiguration}} map --- if they are custom, it's not possible to have hardcoded rules in the operator. As a side note, regarding this last point, I wonder if that's common (I personally don't do that). Maybe the operator could support a syntax similar to Kubernetes, along the lines of: {noformat} flinkConfiguration: my.custom.key: valueFrom: secretKeyRef: ... {noformat} In that case, the operator would inject the values, but I imagine it might not be possible to do it _after_ {{AuditUtils}} has logged the change. In any case, that's just me thinking aloud, I'm not sure anyone would actually need that. was (Author: asardaes): A few more thoughts from me. I'm not sure if it's feasible to cover all scenarios with redaction. Take for example the name of the (potentially internal) repository used in the resource's {{image}}, should that be redacted? Should redaction rules be configurable? For the scenario I initially reported, I did end up changing my resource to use {{valueFrom -> secretKeyRef}} since that covered my needs, but similar to the above, does that really cover all scenarios? Imagine someone wants to inject custom, sensitive values into the {{FlinkDeployment}}'s {{flinkConfiguration}} map --- if they are custom, it's not possible to have hardcoded rules in the operator. As a side note, regarding this last point, I wonder if that's common (I personally don't do that). Maybe the operator could support a syntax similar to Kubernetes, along the lines of: {noformat} flinkConfiguration: my.custom.key: valueFrom: secretKeyRef: ... {noformat} In that case, the operator would inject the valuest, but I imagine it might not be possible to do it _after_ {{AuditUtils}} has logged the change. In any case, that's just me thinking aloud, I'm not sure anyone would actually need that. > Audit utils can expose potentially sensitive information > -------------------------------------------------------- > > Key: FLINK-30306 > URL: https://issues.apache.org/jira/browse/FLINK-30306 > Project: Flink > Issue Type: Improvement > Components: Kubernetes Operator > Affects Versions: kubernetes-operator-1.2.0 > Reporter: Alexis Sarda-Espinosa > Priority: Major > Fix For: kubernetes-operator-1.4.0 > > > I see events being logged by > {{org.apache.flink.kubernetes.operator.listener.AuditUtils}} along the lines > of ">>> Event | Info | SPECCHANGED | UPGRADE change(s) detected". > This logs the entire new spec, which can contain sensitive information that > has been injected from a Kubernetes secret. -- This message was sent by Atlassian Jira (v8.20.10#820010)