GoogleCloudPlatform / flink-on-k8s-operator

[DEPRECATED] Kubernetes operator for managing the lifecycle of Apache Flink and Beam applications.
Apache License 2.0
658 stars 266 forks source link

Mount sensitive Flink Properties as Secrets #383

Open EnriqueL8 opened 3 years ago

EnriqueL8 commented 3 years ago

When setting up security for Flink through the Flink Properties as https://github.com/GoogleCloudPlatform/flink-on-k8s-operator/issues/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 commented 3 years ago

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 commented 3 years ago

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

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

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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