You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
@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.
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
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
we'll add another struct, with 2 available fields,
FromString
andfromSecret
which will be the new struct for the
SecretKey
andAccessKey
fields.the relevant fields in the structs will look like this
so a yaml which will be(excuse my not so correct formatting):
will become end like this:
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
The text was updated successfully, but these errors were encountered: