Add secret mount to operator

[Shinzu]

First initial commit for adding cloud secrets to non cloud environment.

It ties to address #198

[redbaron]

Have you seen #481 ?

[Shinzu]

yes but i think this tackles an other problem

edit: well on the second look it tries to tackle the same problem but in a completely different way.
As mention in the #481 these secrets will not be updated since they are populated via environment variables, unless you 'restart' the pod. This PR populate the secret via Volume mount and this will update the secret in the pod when the secret itself is updated. Also you need only to define 1 environment variable like AWS_SHARED_CREDENTIALS_FILE or GOOGLE_APPLICATION_CREDENTIALS and the corresponding library will take care of reading the file with the credentials. In combination with a controller like kube-aws-iam-controller , that takes care of creating and rotating secrets, this PR provides a more viable way of providing AWS credentials to the pod.

[redbaron]

We keep poorly reinventing pod spec, when is the time to stop? #479

[Shinzu]

@redbaron i'm with you, in the end this is just convenience function for user who don't want to create a whole pod spec

[erthalion]

As we discussed in #479, most likely we would need to have both "modes" - full spec and not full spec. In this sense I believe it makes sense to have this feature for the second mode, what do you think?

[Jan-M]

Looks good to me. @sdudoladov @FxKu

[FxKu]

@Shinzu could you please rebase and resolve the conflicts?

[sdudoladov]

@Shinzu can you please rebase and then we will merge this PR

[Shinzu]

rebase done

[sdudoladov]

👍

[FxKu]

hm, for some reason the config parameters are in single quotes again?

[Shinzu]

@FxKu @sdudoladov re applied the lost changes

[FxKu]

👍

[sdudoladov]

👍

[KarstenSiemer]

Hi!
Can somebody tell me how the secret has to look like exactly? There is no use to saying there is a secret with a json file in it you can attach but putting no information on how it has to look like.
The documentation of WAL-G is only pointing out env variables and spilo is equally silent about how to pass a json.
Thanks!

[Shinzu]

hello, this file just looks like a normal credential file for aws or gcp eg https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html

[KarstenSiemer]

i still do not completely see the full image for getting wal-e to work with baremetal clusters.

Via Custom Pod Environment Variables you can point different cloud SDK's (AWS, GCP etc.) to this mounted secret, e.g. to access cloud resources for uploading logs etc.

AWS, GCP etc.

So one mounts a file with the credentials, this is placed inside the pod but unused, unless i configure env vars to pick up that file.

But, when looking at the documentation of wal-e, only gcp has a variable ("GOOGLE_APPLICATION_CREDENTIALS") for that. AWS doesn't.
How does one pass the credentials file to the aws connector?

[whereismyjetpack]

The behavior of this PR is slightly different than the behavior of injecting these values from the configmap. Mainly, the secret object must live in the namespace where the postgresql object is, and not the operator..

Ideally, for our usecase, we'd specify cloud credentials in the postgres-operator namespace, and the operator would add them to the existing secret that gets created, or to a new cloud credentials secret object.