quay-operator icon indicating copy to clipboard operation
quay-operator copied to clipboard

Stroage Layer configuration Via Yaml - Load from secrets

Open DanArlowski opened this issue 4 years ago • 2 comments

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

DanArlowski avatar Sep 08 '20 12:09 DanArlowski

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

dmesser avatar Sep 08 '20 12:09 dmesser

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

DanArlowski avatar Sep 09 '20 08:09 DanArlowski