Mount sensitive Flink Properties as Secrets

[EnriqueL8]

When setting up security for Flink through the Flink Properties as #309 describes, the following properties are stored in a ConfigMap and mounted into the JobManager and TaskManager containers:

security.ssl.internal.keystore: "/internal.keystore"
security.ssl.internal.truststore: "/internal.keystore"
security.ssl.internal.keystore-password: "internal_store_password"
security.ssl.internal.truststore-password: "internal_store_password"
security.ssl.internal.key-password: "internal_store_password"

These passwords are stored in the ConfigMap, and should instead be stored in a Secret.

Has this been thought about before? or something that could be planned? Thanks!

[functicons]

This is a nice security feature that we could support in the future. I think there are 2 things here: 1) CRD: some properties shouldn't be presented as plain text in the flinkProperties field, instead it should have a flinkPropertiesSecret field which tells the operator to load properties from the secret. 2) the operator should use a Secret instead of a ConfigMap to store the generated flink-conf.yaml.

We welcome your contribution if you could make the PR.

[shashken]

There are 2 problems with this (might not be problems for everyone) ,

• ConfigMap volume on disk is read only - if your solution for secrets is to download them on startup (init container) you wont be able to write them to the created file
• If you want the created file containing secret to be in a memory only volume the only way to achieve that is with a emptyDir with a memory as a medium.

I have a solution if we want to take those problems into consideration but its not as elegant.

• Use flinkPropertiesSecret option in CRD and mount the entire properties into a Secret like @functicons suggested.
• Write the config into a temp directory.
• Create the config directory to be an emptyDir with a memory medium.
• Create an init container that copies the temp dir into the config dir (internal to the operator, the user won't have to define anything) - (cp /tempdir/flink-conf.yaml /opt/flink/conf)

More complex but supports all secret solutions. I can go ahead and make a PR for this if this gets approved. What do you think?
@functicons @EnriqueL8

[chrispatmore]

The only problem with this, is you lose the ability to react to updates to the configmap without restarting the pod. However it seems like we are limited by the capabilities of Flink configuration here. So if the loss of those while running updates is fine, then this approach seems sensible to me

[functicons]

@shashken LGTM, but can we do it in a way that use tempDir/emptyDir and init container only when necessary? Because most of the cases the current design is good enough and simpler.

[shashken]

Thanks for the feedback, ill try to create a PR this week. And the flag you suggested sounds like a good idea, ill try to do that @functicons