summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJason Dunsmore <jasondunsmore@gmail.com>2016-11-16 15:54:02 -0600
committerJason Dunsmore <jasondunsmore@gmail.com>2017-01-21 07:39:06 -0600
commitac23b4b890487eecbfbf147b67300205438a9cdc (patch)
treec237815052d7028e7d8ed65abf45ec209373e819
parent0cc158a9f67d5603436090aad73788b01dc0cabb (diff)
Add spec for phase 1 of cluster creds management
Notes
Notes (review): Code-Review+2: Spyros Trigazis <strigazi@gmail.com> Code-Review+2: Ton Ngo <ton@us.ibm.com> Code-Review+2: Adrian Otto <adrian.otto@rackspace.com> Workflow+1: Adrian Otto <adrian.otto@rackspace.com> Verified+2: Jenkins Submitted-by: Jenkins Submitted-at: Mon, 23 Jan 2017 15:18:51 +0000 Reviewed-on: https://review.openstack.org/399731 Project: openstack/magnum-specs Branch: refs/heads/master
-rw-r--r--specs/ocata/cluster-creds-management-phase-1.rst134
1 files changed, 134 insertions, 0 deletions
diff --git a/specs/ocata/cluster-creds-management-phase-1.rst b/specs/ocata/cluster-creds-management-phase-1.rst
new file mode 100644
index 0000000..0ecab0f
--- /dev/null
+++ b/specs/ocata/cluster-creds-management-phase-1.rst
@@ -0,0 +1,134 @@
1..
2 This work is licensed under a Creative Commons Attribution 3.0 Unported
3 License.
4
5 http://creativecommons.org/licenses/by/3.0/legalcode
6
7=================================
8Cluster creds management, phase 1
9=================================
10
11Launchpad blueprint:
12
13https://blueprints.launchpad.net/magnum/+spec/revoke-cluster-cert
14
15Give cluster admins and owners a way to manage credentials/access to
16the cluster.
17
18Problem Description
19===================
20
21Currently, magnum does not support cluster credential management. This
22is a problem for cluster admins and owners as they are unable to
23restrict/deny access to an existing cluster once a user has been
24granted access.
25
26Use Cases
27=========
28
29This feature is required if, for example, a user leaves an
30organization and his access to a cluster needs to be revoked.
31
32Proposed change
33===============
34
35This blueprint will be implemented in 2 phases.
36
37In the first phase, we'll implement a method to replace the cluster
38certificate. This is mainly to provide at least one method of creds
39management to cluster admins and owners as soon as possible.
40
41This operation will invalidate all user credentials. Since there is
42only one set of credentials for a cluster, once the credentials are
43revoked all users' access will be revoked. All users will need to
44create new certificates to gain access to the cluster again. This will
45allow admins and owners to revoke a user's keystone credentials and
46thus deny them access to the cluster.
47
48If the cluster is non-TLS, an error will be returned to the user.
49
50The CA certificate data stored in barbican will be modified when the
51CA certificate is rotated.
52
53In phase 2, we'll implement a finer-grained approach to cert
54revocation, which will require magnum to start storing a mapping
55between a keystone user and the certs they have generated in
56magnum. This will allow admins and owners to list users for each
57cluster and revoke certs for a specific user. Before this is possible,
58we must contribute to Docker/Kubernetes/Mesos in order to support cert
59revocation lists.
60
61Implementation
62==============
63
64Work Items
65----------
66
67Invoke the make-cert.py script and generate a new certificate using
68the existing keystone trust that's on the node, and restart Swarm or
69Kubernetes and configure it to use the new certificate.
70
71Assignee(s)
72-----------
73
74Primary assignee:
75 Jason Dunsmore (jasondunsmore)
76
77Milestones
78----------
79
80Target Milestone for completion:
81 ocata-3
82
83REST API Impact
84===============
85
86The /certificates api will need to be modified to support the new
87operation. A REST API will be added for::
88
89 PATCH /certificates/{cluster_id}
90
91Rationale for using PATCH:
92
93TLS certificate management has the concept of "re-issue" of a
94compromised certificate. This process is used when the private key has
95been compromised. In the use case of an employee leaving the
96organization, that's technically what has happened.
97
98Technically speaking a new version of the same certificate with the
99same CSR is signed by the CA again with a new key, and issued again
100with the intent to replace the previous certificate with an equivalent
101one that has a different key, but the same CA and expiration
102date. This procedure is also known as "rekeying" a certificate.
103
104Given the existing process, a PATCH action is appropriate. The
105mechanism is not intented to be used for things like changing the
106Certificate Authority, or extending the expiry of a certificate. Those
107actions would be deletions followed by re-issuing a completely
108different replacement certificate with a different expiration date.
109
110Security Impact
111===============
112
113Admins and owners will have the ability to revoke user access to a
114cluster, which is needed for certain security protocols.
115
116If an unwanted user has access to magnum's API, he can simply re-issue
117a cert. For a block to a user to be successful, his access to magnum's
118API needs to be revoked.
119
120Alternatives
121============
122
1231) Manage credentials outside of magnum as a manual process.
1242) Wait for Kubernetes support for cluster certificate management.
125
126Documentation Impact
127====================
128
129Will update docs on the usage of this new feature.
130
131Dependencies
132============
133
134None identified.