Initial spec for separate CA for k8s and etcd
Story: 2008833 Signed-off-by: Zhipeng Liu <zhipengs.liu@intel.com> Change-Id: If3944239ea4d7bf96787f3d2fa1e7aa1414b62c5
This commit is contained in:
parent
489c55f085
commit
18f4482b4a
|
@ -0,0 +1,162 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License. http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
=============================
|
||||
Separate CA for k8s and etcd
|
||||
=============================
|
||||
Storyboard:
|
||||
https://storyboard.openstack.org/#!/story/2008833
|
||||
|
||||
This proposal will separate CA for k8s and etcd
|
||||
|
||||
Problem description
|
||||
===================
|
||||
Currently, we are reusing kubernetes-ca for etcd but not using a separate CA.
|
||||
Making one single root CA by copying the root certificate/key would blur the
|
||||
boundary of certificates for apiserver and etcd.
|
||||
It may cause unforeseen complexities for future features. kubernetes-ca and
|
||||
etcd-ca have different purposes and usage.
|
||||
Sharing cert between kubernetes-ca and etcd-ca will dramatically increase the
|
||||
complexity of updating etcd-ca cert.
|
||||
We'd better refer to the best practice for k8s and etcd certs in [1]_
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
|
||||
* Admin wants to use a separate external root CA for etcd and k8s.
|
||||
* Admin wants to maintain the root CA for etcd and k8s separately
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
**Fresh Deployment**
|
||||
|
||||
#. Generate self-signed CA certificate for etcd before apply bootstrap manifest
|
||||
|
||||
Generate a unique CA for etcd and related certs.
|
||||
Copy apiserver-etcd-client.crt/key to /etc/kubernetes/pki/
|
||||
Copy etcd ca and etcd-server crt/key to /etc/etcd/
|
||||
Do not modify the Kubernetes-ca in /etc/kubernetes/pki/
|
||||
Change etcd-ca and certs paths, that will be used by api-server in
|
||||
playbookconfig/src/playbooks/roles/common/files/kubeadm.yaml.erb
|
||||
|
||||
**Changes for upgrade process**
|
||||
|
||||
|
||||
* Simplex
|
||||
|
||||
For simplex upgrade, it will use restore procedure during installing the new starlingx
|
||||
software. So we need to generate etcd-ca separately before apply bootstrap manifest for
|
||||
etcd during restore procedure, that is similar like we do for fresh deployment.
|
||||
|
||||
* Duplex/Multi-node
|
||||
During upgrade-activate stage, we will do below
|
||||
1) Create /etc/kubernetes/pki/etcd/ subfolder, and generate etcd-ca and related certs
|
||||
2) Copy etcd-ca and related certs to /etc/kubernetes/pki/etcd/ and /etc/etcd/
|
||||
3) Restart etcd, and update the config of api-server before restart it.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
None
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
It can reduce the security risk after separate k8s CA and etcd CA
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
none
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
none
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
Admin user is able to use separate external root ca cert for k8s and etcd
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
Upgrade impact
|
||||
--------------
|
||||
|
||||
It has already been described in section `Proposed change`_
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
|
||||
Repos Impacted
|
||||
--------------
|
||||
|
||||
ansible-playbooks
|
||||
stx-puppet
|
||||
config
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
The work items have already been described in section `Proposed change`_
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
* Deployment test on both simplex and duplex.
|
||||
* Switch active controller.
|
||||
* Lock/unlock of a simplex controller.
|
||||
* Backup/Restore test on simplex and duplex.
|
||||
* Spontaneous reboot of a simplex controller.
|
||||
* Re-installing a controller host on a duplex setup and
|
||||
then swacting to it.
|
||||
* Upgrade test on both simplex and duplex.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [1] https://kubernetes.io/docs/setup/best-practices/certificates/
|
||||
|
||||
|
||||
History
|
||||
=======
|
||||
|
||||
.. list-table:: Revisions
|
||||
:header-rows: 1
|
||||
|
||||
* - Release Name
|
||||
- Description
|
||||
* - stx.6.0
|
||||
- Separate CA for k8s and etcd
|
Loading…
Reference in New Issue