-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Populate pod environment variables from secrets #481
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Coverage remained the same at 23.705% when pulling cfa128d701e105f9d3adf19c91e906e674baeea9 on kupson:podenv-via-secrets into ba23de3 on zalando-incubator:master. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it worth mentioning that the operator will not sync this secret unlike some others secrets
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated the MR to mention that SecretKeySelector is used to reference secret's key. Do you think that's good enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be fixed by kupson@2fa68d1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means there will be a single k8s secret with env vars shared between all pods of PG clusters. In the case of minio this is valid behavior, otherwise one would need to setup access control. This needs at least some documentation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's consistent with behaviour of PodEnvironmentConfigMap - a single ConfigMap that's shared between all pods.
I think of PodEnvironmentSecretName/PodEnvironmentSecretKeys as of secret version of PodEnvironmentConfigMap.
pkg/cluster/k8sres.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why sorting ? to simplify displaying ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved it moved from:
postgres-operator/pkg/cluster/k8sres.go
Lines 777 to 778 in 5f6abfb
| sort.Slice(customPodEnvVarsList, | |
| func(i, j int) bool { return customPodEnvVarsList[i].Name < customPodEnvVarsList[j].Name }) |
That's because the customPodEnvVarsList is being appended not only by PodEnvironmentConfigMap code but also PodEnvironmentSecretName.
…nvironment_secret_name
cfa128d to
aa99b59
Compare
Results of:
hack/update-codegen.sh
Use impossible symbol \x00 as a separator. This ensures that "AB: CD" and "A: BCD" produce different hashes.
…o separate functions - better variable names - better error handling
Now this function only handles Pod environment variables and it's hashes.
9b4c6f8 to
01a007a
Compare
Logs:
spec diff between old and new statefulsets:
Template.ObjectMeta.Annotations: map[string]string(nil) != map[string]string{}
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Template.Spec.InitContainers[0].TerminationMessagePath: "/dev/termination-log" != ""
Template.Spec.InitContainers[0].TerminationMessagePolicy: "File" != ""
Template.Spec.InitContainers[0].ImagePullPolicy: "Always" != ""
Template.Spec.Containers[0].TerminationMessagePath: "/dev/termination-log" != ""
Template.Spec.Containers[0].TerminationMessagePolicy: "File" != ""
Template.Spec.RestartPolicy: "Always" != ""
Template.Spec.DNSPolicy: "ClusterFirst" != ""
Template.Spec.DeprecatedServiceAccount: "infra-postgres-operator-dev-dmz1-comm-patroni" != ""
Template.Spec.SecurityContext: &v1.PodSecurityContext{} != nil
Template.Spec.SchedulerName: "default-scheduler" != ""
Template.Spec.Tolerations: []v1.Toleration(nil) != []v1.Toleration{}
VolumeClaimTemplates[0].Status.Phase: "Pending" != ""
PodManagementPolicy: "OrderedReady" != ""
UpdateStrategy.Type: "OnDelete" != ""
RevisionHistoryLimit: &int32(10) != nil
2028cae to
bd0df37
Compare
|
It would be suboptimal as it would require some scripting at the Patroni container start. Patroni is configured by environment variables so this approach seems more natural -- why use Volumes for configuration imported for secrets but otherwise have The BTW: Any change in the source Secrets would cause annotation update and Pod restart so the Env variables would be in sync with the Secret values. |
|
@FxKu ... we just reached the same issue @kupson was having about the configuration of the Spilo startup. See my remarks / analysis in comment: #858 (comment) I was about to open a new issue / discussion regarding proper "multi tenancy" configuration of the operators' S3 configuration. Would you reconsider this PR or even want to rework the cloud credential handling to allow i.e. "k8s namespaces" / "teams" / "tenants" to bring their own buckets and cloud credentials. With the centrally configured bucket, shared AWS credentials and even with s3:prefix filters in the bucket policy no real protection apart from the random UID in the path (which one needs to know) there always remains the danger that someone fetched backups of a fully unrelated database not even belonging to team / namespace. |
… highly inspired by @kupson and his very similar PR zalando#481
* Extend operator configuration to allow for a pod_environment_secret just like pod_environment_configmap * Add all keys from PodEnvironmentSecrets as ENV vars (using SecretKeyRef to protect the value) * Apply envVars from pod_environment_configmap and pod_environment_secrets before doing the global settings from the operator config. This allows them to be overriden by the user (via configmap / secret) * Add ability use a Secret for custom pod envVars (via pod_environment_secret) to admin documentation * Add pod_environment_secret to Helm chart values.yaml * Add unit tests for PodEnvironmentConfigMap and PodEnvironmentSecret - highly inspired by @kupson and his very similar PR #481 * Added new parameter pod_environment_secret to operatorconfig CRD and configmap examples * Add pod_environment_secret to the operationconfiguration CRD Co-authored-by: Christian Rohmann <[email protected]>
Fixes #480.
Example Secret:
Configuration:
Generated Pod config snippet: