Users may very likely want to have tokens issued from some other security provider, such as Vault or perhaps some cloud specific system. As such, it would be good to at least leave the model open such that various token provider backends may be used.
Review any such possibilities, primarily with Vault or SealedSecrets.
If there are such possibilities which match with the Hadron use case, then review if we should refactor the Token CRD or just leave open a design for new CRD types which could be specific to the various backends.
Users
Ultimately the plan is to support basic auth user creds for access to the observability/metrics/monitoring interface exposed by Hadron.
With the new User CRD, we will likely have the model define a reference to a secret in the same cluster, and the credentials will be extracted from the secret and used as a source for user auth.
This approach would work well with standard k8s basic-auth secrets as well as SealedSecrets (ultimately the same thing), and any other option which generates a k8s manifest which we can reference.
thedodd
commented
3 years ago
Tokens
Users may very likely want to have tokens issued from some other security provider, such as Vault or perhaps some cloud specific system. As such, it would be good to at least leave the model open such that various token provider backends may be used.
TokenCRD or just leave open a design for new CRD types which could be specific to the various backends.Users
Ultimately the plan is to support basic auth user creds for access to the observability/metrics/monitoring interface exposed by Hadron.
UserCRD, we will likely have the model define a reference to a secret in the same cluster, and the credentials will be extracted from the secret and used as a source for user auth.