Separate etcd certificates #3777
Conversation
|
/rebase |
1 similar comment
|
/rebase |
| @@ -26,7 +26,9 @@ type Etcd struct { | |||
|
|
|||
| // EtcdCertsSpec describes etcd certs secrets. | |||
| type EtcdCertsSpec struct { | |||
| EtcdPeer *x509.PEMEncodedCertificateAndKey `yaml:"etcdPeer"` | |||
| EtcdPeer *x509.PEMEncodedCertificateAndKey `yaml:"etcdPeer"` | |||
There was a problem hiding this comment.
do we need EtcdPeer and EtcdClient here?
There was a problem hiding this comment.
get etcdsecrets.secrets.talos.dev -oyaml -- looks nice
And you can check all certs.
https://github.com/talos-systems/talos/pull/3777/files#diff-f028d821b1f248fa75f380f9a91477df94583726a996ead5f16b089ec24baf04R130 here updateSecrets func recreate the certs
sergelogvinov
force-pushed
the
etcd-certs
branch
3 times, most recently
from
37864fb
to
f67c7a0
Compare
| @@ -147,6 +147,8 @@ func (e *Etcd) Runner(r runtime.Runtime) (runner.Runner, error) { | |||
| env = append(env, "ETCD_UNSUPPORTED_ARCH=arm64") | |||
| } | |||
|
|
|||
| env = append(env, "ETCD_CIPHER_SUITES=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305") //nolint:lll | |||
There was a problem hiding this comment.
what is the effect of this line on etcd security/performance?
There was a problem hiding this comment.
ref (one of them): etcd-io/etcd#10304
There was a problem hiding this comment.
- AES 128/256 with RSA/ECDSA for CPU with AES-IN
- chacha-poly with RSA/ECDSA for ARM
https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/
etcd cluster works inside the tales cluster, and it does not support to connect external etcd nodes. We can set less choice but with better performance.
|
|
||
| opts = append(opts, | ||
| x509.ExtKeyUsage([]stdlibx509.ExtKeyUsage{ | ||
| stdlibx509.ExtKeyUsageServerAuth, |
There was a problem hiding this comment.
should we have both client and server cert to be same cert? or should we split client and server certs?
not sure what is the best practice for etcd
There was a problem hiding this comment.
definitely yes.
But etcd uses this cert to check itself.
- https://kubernetes.io/docs/setup/best-practices/certificates/ uses both (clientAuth, serverAuth)
- https://github.com/kubernetes-sigs/kubespray/blob/master/roles/etcd/templates/openssl.conf.j2 uses both (clientAuth, serverAuth)
I've add talos etcd client cert, now we have 4 certs for etcd cluster.
sergelogvinov
force-pushed
the
etcd-certs
branch
from
f67c7a0
to
c3e8f9a
Compare
|
👍 this looks good to me, I want to do a little bit of optimization to skip generating etcd certs twice in the controller and service code. I will push to this PR resolving conflicts. |
Changes: * Etcd peer port key usage: ServerAuth,ClientAuth * Etcd client port key usage: ServerAuth,ClientAuth * Talos etcd client key usage: ClientAuth * KubeAPI etcd client key usage: ClientAuth * List of etcd allowed ciphers Signed-off-by: Serge Logvinov <[email protected]> Signed-off-by: Andrey Smirnov <[email protected]>
|
/approve |
|
/lgtm |
Pull Request
Fixes #3092
Fixes #3091
Acceptance
Please use the following checklist:
make conformance)make fmt)make lint)make docs)make unit-tests)This change is