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

Stroage Layer configuration Via Yaml - Load from secrets #309

Open
DanArlowski opened this issue Sep 8, 2020 · 2 comments
Open

Stroage Layer configuration Via Yaml - Load from secrets #309

DanArlowski opened this issue Sep 8, 2020 · 2 comments

Comments

@DanArlowski
Copy link

Hi,

When we're deploying a new Quayecosystem, we define all configuration via the CR yaml.
unfortunately, we didn't really like the section where you define the secret key(s and access keys) as a string,
and we would like to allow doing it from a secret pre-deployed to the project(/namespace), just like some other configurations.
this will allow better secret handling, and will increase trust by users, as no hard coded secret key strings will be saved in the CR file.

we'll take Rados as an example (but the same applies to most storages),
i'll refer to v1 branch (as master is a wee bit off right now)

what i was thinking of implementing is this:

the Rados struct

type RADOSRegistryBackendSource struct {
	StoragePath string `json:"storagePath,omitempty,name=storagePath"`
	BucketName  string `json:"bucketName,omitempty,name=bucketName"`
	AccessKey   string `json:"accessKey,omitempty,name=accessKey"`
	SecretKey   string `json:"secretKey,omitempty,name=secretKey"`
	Hostname    string `json:"hostname,omitempty,name=hostname"`
	Secure      bool   `json:"secure,omitempty,name=secure"`
	Port        int    `json:"port,omitempty,name=port"`
}

we'll add another struct, with 2 available fields, FromString and fromSecret
which will be the new struct for the SecretKey and AccessKey fields.

the relevant fields in the structs will look like this

type StorageAuthentication sturct{
  FromString string             `json:"fromString,omitempty,name=fromString"`
  FromSecret *SecretKeySelector `json:"fromSecret,omitempty,name=fromSecret"`
}
type RADOSRegistryBackendSource struct {
...
	AccessKey   *StorageAuthentication `json:"accessKey,omitempty,name=accessKey"`
	SecretKey   *StorageAuthentication `json:"secretKey,omitempty,name=secretKey"`
...
}

so a yaml which will be(excuse my not so correct formatting):

...
rados:
  storagePath: PATH_TO_STORAGE
  bucketName: BUCKET
  accessKey: ACCESS_KEY
  secretKey: SECRET_KEY

will become end like this:

rados:
  storagePath: PATH_TO_STORAGE
  bucketName: BUCKET
  accessKey: 
    fromString: ACCESS_KEY
  secretKey:
    fromSecret: 
      secretKeyRef:
        name: SECRET_NAME
        key: SECRET_KEY

the fromSecret will hold the struct secretKeySelector [1] just like loading env vars into pods

if both fields are present, we will take the first one listed

of course also add validation relevant and all the logic will implemented.

I'll be glad to hear your thoughts on that.
I tried to be as clear with my intentions as possible.

Thanks.

Dan

[1] https://godoc.org/k8s.io/api/core/v1#SecretKeySelector

@dmesser
Copy link
Contributor

dmesser commented Sep 8, 2020

@DanArlowski Thanks for this submission. As you probably already noticed, the Quay Operator is undergoing some major re-design. It is managing the entire Kubernetes-level configuration in a very opinionated fashion whereas the Quay-level configuration happens entirely within Quay config bundles (which is implemented as a Kubernetes Secret).

That said, in regards to your proposal, the access credentials for any storage backend will live in the config bundle and are not maintained via the Custom Resource anymore.

@DanArlowski
Copy link
Author

Hi,
If i got you correctly, that means that the configurations via the yaml will be deprecated, and that the only way to configure quay will be via the quay-config pod.

that is understandable, and reproducible via exporting-importing configurations.

will there be a possibility to deploy quay with the configuration pre-configured like the CR configuration?
That is a requirement we have

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants