Closed georgethebeatle closed 2 years ago
I think this has some overlap with https://github.com/cloudfoundry/cf-k8s-controllers/issues/796, this one might be better suited toward driving out those changes on the LRP Spec, but I wanted to link it here for reference as well.
I've created a PR for this in the eirini-controllers repo: https://github.com/cloudfoundry/eirini-controller/pull/19
Blockers/Dependencies
Background
Right now the process controller of cf-k8s is forced to load all env var values from a k8s secret and set them on the LRP as string key value pairs, which means the information that is potentially sensitive for the app can be exposed to whoever has permission to read LRPs on the cluster.
This defect is due to today's LRP definition and should be fixed so that users of Eirini can set env vars with values coming from Secrets, ConfigMaps, etc.
As a Eirini user I want to be able to create LRPs with env values from secrets So that I do not expose sensitive app information
Acceptance Criteria
GIVEN I have read/write permissions for LRPs in the cluster WHEN I I apply the following yml
THEN I expect it to be accepted AND I expect my app to have both the
foo: bar
and thepassword: s33msi4
env vars setDev Notes
In order to keep Eirini's contract backwards compatible we could introduce a new field for env vars of type
[]corev1.EnvVar
next to the current one and deprecate the current one. The implementation would merge the values in the two env var fields thus not breaking old clients, but giving new clients the opportunity to hide their env values in secrets. Eventually after some time we would delete the deprecated field.