Browse Source

Add spec for phase 1 of cluster creds management

blueprint revoke-cluster-cert

Change-Id: Ie960464e45445e195e75b91e8d65a4046eb21e93
Jason Dunsmore 2 years ago
parent
commit
ac23b4b890
1 changed files with 134 additions and 0 deletions
  1. 134
    0
      specs/ocata/cluster-creds-management-phase-1.rst

+ 134
- 0
specs/ocata/cluster-creds-management-phase-1.rst View File

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

Loading…
Cancel
Save