Merge "Add spec for phase 1 of cluster creds management"
This commit is contained in:
commit
48ab123a6d
|
@ -0,0 +1,134 @@
|
||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
=================================
|
||||||
|
Cluster creds management, phase 1
|
||||||
|
=================================
|
||||||
|
|
||||||
|
Launchpad blueprint:
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/magnum/+spec/revoke-cluster-cert
|
||||||
|
|
||||||
|
Give cluster admins and owners a way to manage credentials/access to
|
||||||
|
the cluster.
|
||||||
|
|
||||||
|
Problem Description
|
||||||
|
===================
|
||||||
|
|
||||||
|
Currently, magnum does not support cluster credential management. This
|
||||||
|
is a problem for cluster admins and owners as they are unable to
|
||||||
|
restrict/deny access to an existing cluster once a user has been
|
||||||
|
granted access.
|
||||||
|
|
||||||
|
Use Cases
|
||||||
|
=========
|
||||||
|
|
||||||
|
This feature is required if, for example, a user leaves an
|
||||||
|
organization and his access to a cluster needs to be revoked.
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
This blueprint will be implemented in 2 phases.
|
||||||
|
|
||||||
|
In the first phase, we'll implement a method to replace the cluster
|
||||||
|
certificate. This is mainly to provide at least one method of creds
|
||||||
|
management to cluster admins and owners as soon as possible.
|
||||||
|
|
||||||
|
This operation will invalidate all user credentials. Since there is
|
||||||
|
only one set of credentials for a cluster, once the credentials are
|
||||||
|
revoked all users' access will be revoked. All users will need to
|
||||||
|
create new certificates to gain access to the cluster again. This will
|
||||||
|
allow admins and owners to revoke a user's keystone credentials and
|
||||||
|
thus deny them access to the cluster.
|
||||||
|
|
||||||
|
If the cluster is non-TLS, an error will be returned to the user.
|
||||||
|
|
||||||
|
The CA certificate data stored in barbican will be modified when the
|
||||||
|
CA certificate is rotated.
|
||||||
|
|
||||||
|
In phase 2, we'll implement a finer-grained approach to cert
|
||||||
|
revocation, which will require magnum to start storing a mapping
|
||||||
|
between a keystone user and the certs they have generated in
|
||||||
|
magnum. This will allow admins and owners to list users for each
|
||||||
|
cluster and revoke certs for a specific user. Before this is possible,
|
||||||
|
we must contribute to Docker/Kubernetes/Mesos in order to support cert
|
||||||
|
revocation lists.
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
Invoke the make-cert.py script and generate a new certificate using
|
||||||
|
the existing keystone trust that's on the node, and restart Swarm or
|
||||||
|
Kubernetes and configure it to use the new certificate.
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
Jason Dunsmore (jasondunsmore)
|
||||||
|
|
||||||
|
Milestones
|
||||||
|
----------
|
||||||
|
|
||||||
|
Target Milestone for completion:
|
||||||
|
ocata-3
|
||||||
|
|
||||||
|
REST API Impact
|
||||||
|
===============
|
||||||
|
|
||||||
|
The /certificates api will need to be modified to support the new
|
||||||
|
operation. A REST API will be added for::
|
||||||
|
|
||||||
|
PATCH /certificates/{cluster_id}
|
||||||
|
|
||||||
|
Rationale for using PATCH:
|
||||||
|
|
||||||
|
TLS certificate management has the concept of "re-issue" of a
|
||||||
|
compromised certificate. This process is used when the private key has
|
||||||
|
been compromised. In the use case of an employee leaving the
|
||||||
|
organization, that's technically what has happened.
|
||||||
|
|
||||||
|
Technically speaking a new version of the same certificate with the
|
||||||
|
same CSR is signed by the CA again with a new key, and issued again
|
||||||
|
with the intent to replace the previous certificate with an equivalent
|
||||||
|
one that has a different key, but the same CA and expiration
|
||||||
|
date. This procedure is also known as "rekeying" a certificate.
|
||||||
|
|
||||||
|
Given the existing process, a PATCH action is appropriate. The
|
||||||
|
mechanism is not intented to be used for things like changing the
|
||||||
|
Certificate Authority, or extending the expiry of a certificate. Those
|
||||||
|
actions would be deletions followed by re-issuing a completely
|
||||||
|
different replacement certificate with a different expiration date.
|
||||||
|
|
||||||
|
Security Impact
|
||||||
|
===============
|
||||||
|
|
||||||
|
Admins and owners will have the ability to revoke user access to a
|
||||||
|
cluster, which is needed for certain security protocols.
|
||||||
|
|
||||||
|
If an unwanted user has access to magnum's API, he can simply re-issue
|
||||||
|
a cert. For a block to a user to be successful, his access to magnum's
|
||||||
|
API needs to be revoked.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
============
|
||||||
|
|
||||||
|
1) Manage credentials outside of magnum as a manual process.
|
||||||
|
2) Wait for Kubernetes support for cluster certificate management.
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
Will update docs on the usage of this new feature.
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
None identified.
|
Loading…
Reference in New Issue