-
Notifications
You must be signed in to change notification settings - Fork 15
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
Auth design #87
Draft
Kirill-Garbar
wants to merge
1
commit into
main
Choose a base branch
from
auth-design
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Auth design #87
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,55 @@ | ||
# Authentication, authorization and secure communication | ||
|
||
* Status: proposed | ||
* Date: 2024-04-03 | ||
|
||
Guthub issue: https://github.com/aenix-io/etcd-operator/issues/76 | ||
|
||
## Security specification | ||
|
||
``` | ||
kind: EtcdCluster | ||
spec: | ||
... | ||
security: | ||
peer: | ||
caSecretName: peer-ca-tls-secret | ||
tlsSecretName: peer-server-tls-secret | ||
clientServer: | ||
caSecretName: client-server-ca-tls-secret | ||
tlsSecretName: client-server-server-tls-secret | ||
auth: | ||
tlsSecretName: client-server-client-tls-secret | ||
... | ||
``` | ||
|
||
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Secret sections (filenames) will be hardcoded to decrease configuration complexity |
||
|
||
All fields are optional, but if one field is defined in a pair (caSecretName and tlsSecretName), other must be defined as well - it will be validated in a webhook. | ||
|
||
## Peer communication | ||
If peer secrets are not defined, then `--peer-auto-tls` option is used that allows etcd to communicate via https. | ||
|
||
If peer certificate/key is reissued, etcd cluster does rollout restart to reread the secret. Operator watches these secrets. | ||
|
||
One secret is used for all etcd nodes. | ||
|
||
## Client-server communication | ||
If client-server secrets are not defined, then `--auto-tls` option is used that allows clients to communicate via https. | ||
|
||
If client-server certificate/key is reissued, etcd cluster does rollout restart to reread the secret. Operator watches these secrets. | ||
|
||
## User authentication | ||
If enabler is true, user authentication is enabled and `root` user is created in etcd without a password. It is expected that customer provides valid secret for operator authentication (to operate etcd cluster) with `tls.crt` and `tls.key` sections. As multiple secrets for multiple etcd clusters are created on the fly, secrets are not mounted to operator => secrets are read on the fly and reread by operator if certificates are reissued. | ||
|
||
If `auth.tlsSecretName` is defined, then the whole `clientServer` section must be defined as well => validated in a webhook. | ||
|
||
## Futher improvements to be described and discussed | ||
|
||
1. * What: Use separate controller (CR) to create k8s secrets with certificates/passwords and renew them relularly. | ||
* Why: | ||
* Etcd clients (apps deployed to k8s) will need to have possibility to access created etcd clusters. It would be inconvenient to couple user lists in EtcdCluster CR (with complete RBAC lists) with users in the application configurations. | ||
2. * What: Remove cert-manager dependency to create and rotate certificates. | ||
* Why: | ||
* Openshift has its own ecosystem and doesn't have cert-manager out of the box. It has own operator. | ||
* Cert-manager dependency (ceparate operator) is too heavy for etcd-operator. |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.