Skip to content
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

Populate pod environment variables from secrets #481

Closed
wants to merge 19 commits into from

Conversation

kupson
Copy link
Contributor

@kupson kupson commented Feb 4, 2019

Fixes #480.

Example Secret:

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: minio-secret-test
data:
  access_key: dGVzdAo=
  secret_key: dGVzdAo=

Configuration:

apiVersion: acid.zalan.do/v1
configuration:
  ...
  kubernetes:
    ...
    pod_environment_secret_name: minio-secret-test
    pod_environment_secret_keys:
      access_key: AWS_ACCESS_KEY_ID
      secret_key: AWS_SECRET_ACCESS_KEY

Generated Pod config snippet:

  env:
    - name: AWS_ACCESS_KEY_ID
      valueFrom:
        secretKeyRef:
          key: access_key
          name: minio-secret-test
    - name: AWS_SECRET_ACCESS_KEY
      valueFrom:
        secretKeyRef:
          key: secret_key
          name: minio-secret-test

pkg/cluster/k8sres.go Outdated Show resolved Hide resolved
@coveralls
Copy link

coveralls commented Feb 4, 2019

Coverage Status

Coverage remained the same at 23.705% when pulling cfa128d701e105f9d3adf19c91e906e674baeea9 on kupson:podenv-via-secrets into ba23de3 on zalando-incubator:master.

docs/administrator.md Outdated Show resolved Hide resolved
variable is the same as the secret's key. On conflicts they are overridden by
the environment variables generated by the operator. The
`pod_environment_secret_keys` option can be used to choose keys to populate and
change environment variables names. The default is empty.
Copy link
Member

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

Copy link
Contributor Author

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?

Copy link
Contributor Author

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

PodEnvironmentConfigMap string `json:"pod_environment_configmap,omitempty"`
PodEnvironmentSecretName string `json:"pod_environment_secret_name,omitempty"`
PodEnvironmentSecretKeys map[string]string `json:"pod_environment_secret_keys,omitempty"`
PodPriorityClassName string `json:"pod_priority_class_name,omitempty"`
Copy link
Member

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

Copy link
Contributor Author

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.

}
}

sort.Slice(customPodEnvVarsList,
Copy link
Member

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 ?

Copy link
Contributor Author

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:

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.

pkg/cluster/k8sres.go Outdated Show resolved Hide resolved
pkg/cluster/k8sres.go Outdated Show resolved Hide resolved
pkg/cluster/k8sres.go Outdated Show resolved Hide resolved
@kupson kupson changed the title Populate pod environment variables from secrets WIP: Populate pod environment variables from secrets Mar 26, 2019
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
@erthalion erthalion self-assigned this Mar 29, 2019
@kupson kupson changed the title WIP: Populate pod environment variables from secrets Populate pod environment variables from secrets Apr 1, 2019
@FxKu
Copy link
Member

FxKu commented Jun 19, 2019

@kupson we went for the secret mount approach by @Shinzu. With the mounted Volume the secret is always in sync compared to setting env variables. Would this also work for you?

@kupson
Copy link
Contributor Author

kupson commented Jul 2, 2019

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 pod_environment_configmap?

The PGPASSWORD_STANDBY and PGPASSWORD_SUPERUSER environment variables already holds values from secrets. Are there plans to change them to volumes too?

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.

@frittentheke
Copy link
Contributor

frittentheke commented Mar 20, 2020

@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.

frittentheke added a commit to frittentheke/postgres-operator that referenced this pull request Jul 15, 2020
FxKu pushed a commit that referenced this pull request Jul 30, 2020
* 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 <christian.rohmann@inovex.de>
@FxKu
Copy link
Member

FxKu commented Jul 30, 2020

Closing this now as the successor PR #946 got merged. Thanks again @kupson

@FxKu FxKu closed this Jul 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

allow populating pod environment from Secrets
7 participants