Auth design #87
Auth design #87
Conversation
Kirill-Garbar
force-pushed
the
auth-design
branch
3 times, most recently
from
66f2525
to
8d74637
Compare
Kirill-Garbar
force-pushed
the
auth-design
branch
2 times, most recently
from
7b991cc
to
607e718
Compare
| spec: | ||
| ... | ||
| security: | ||
| peer: |
There was a problem hiding this comment.
As no separate enabler is proposed, we will have only 2 states: secrets provided by customer and auto-tls options from etcd.
Will we implement creation of the secrets in the operator with cert-manager objects? If yes, then we need to find a solution how to enable/disable it. Proposal: create in the future additional sections ~operatorManagedCertificates or so. Defined new section and defined secret references can't exist together and will be validated in a webhook.
If we agree that this is good option, then we will not extend specification for now.
There was a problem hiding this comment.
Will we implement creation of the secrets in the operator with cert-manager objects?
The certificate management offered by CloudnativePG seems very good to me.
Essentially, if no values are provided, certs are managed by the Operator. With a user input, instead, the Operator does a look-up to use them.
There was a problem hiding this comment.
Totally agree, I think we have to enable certs generation if nothing specified.
I do not see the case where user would need etcd-cluster without certificates.
There was a problem hiding this comment.
Let's enable certificates generation by operator by default for now, and extend API spec for specifying custom user certificates later.
What do you think @serathius?
There was a problem hiding this comment.
I think, for many users (not k8s control plane) auto-tls for transport encryption and password authentication is enough.
Self-managed certificates are for the future. I would say it is mature logic and it is a bit early to design this rotation before operator is able to operate (fully and reliably) etcd (scale, defrag, backup, restore). I thought the same in the very beginning, that we need to remove cert-manager dependency as soon as possible, but after that I though one more time:
- Cert-manager is used by (I assume) every mature platform.
- Even if it is not used => easy to install.
- The only problem - Openshift where they have their own PKI infra. This problem should be investigated. Even there certman can be installed.
I assumed that operator will create cert-manager objects in the code and will depend on the installed cert-manager operator with its CRDs.
There was a problem hiding this comment.
I would base this on the fact that the primary users for now are hosted Kubernetes control planes. We're ready to adopt the operator as soon as it offers a stable spec and a feature for managing x509 certificates.
I have nothing against using cert-manager. I was just considering that implementing basic logic for generating certificates (even for 10 years) might be simpler than agreeing on and stabilizing the spec for external certificate management at this phase.
| ... | ||
| ``` | ||
|
|
||
| It is expected that secrets contain sections with specific names: `tls.crt`, `tls.key` for tlsSecret and `ca.crt` for caSecret. |
There was a problem hiding this comment.
Secret sections (filenames) will be hardcoded to decrease configuration complexity
Kirill-Garbar
force-pushed
the
auth-design
branch
from
607e718
to
cae45e1
Compare
|
Could you please move to design subdirectory into website |
Guthub issue: #76