This will give admins a way to revoke access to an existing cluster
once a user has been granted access.
Bumped the API microversion to 1.5 for the new endpoint.
Deprecated policy certificate:get in favor of certificate:get_ca for
clarity and consistency.
Depends-On: Ie960464e45445e195e75b91e8d65a4046eb21e93
Implements: blueprint revoke-cluster-cert
Change-Id: Ief28bef3a79f212acf4166e443a96e5419fbb757
* Add osprofiler wsgi middleware. This middleware is used for 2 things:
1) It checks that person who wants to trace is trusted and knows
secret HMAC key.
2) It starts tracing in case of proper trace headers
and adds first wsgi trace point, with info about HTTP request
* Add initialization of osprofiler at start of service
Currently that includes oslo.messaging notifer instance creation
to send Ceilometer backend notifications.
* Traces HTTP/RPC/DB API calls
Demo: https://hieulq.github.io/cluster-create-false-new-html.html
Co-Authored-By: Hieu LE <hieulq@vn.fujitsu.com>
Implements: blueprint osprofiler-support-in-magnum
Change-Id: I7d68995aab81d365433950aada078ef1fcd5469b
This is patch #2 of 3 to rename the term bay to cluster within
the internal references and objects of magnum. This patch changes
all references to the certificate objects bay_uuid field to
cluster_uuid. Certifcate does not have a db table so no db
changes were made. No functionality is changed by this patch,
just internal naming.
Change-Id: I68a3b87b75b49de43a7855355807b50a4ae695f3
Implements: blueprint rename-bay-to-cluster
This sets up three files for clients that accept TLS certs as files:
* CA Certificate
* Magnum's Client Private Key
* Magnum's Client Certificate
The Client Private Key is decrypted as some clients cannot handle
encrypted private keys.
Partially Implements bp secure-docker
Change-Id: I14ca6b1ad520bd8391e119c7e016d765cae32f6b
Updated tox.ini and fixed rules.
Fix H405:
Multi line docstring summary not separated with an empty line
Fix E131:
Continuation line unaligned for hanging indent
Change-Id: I20cf75c75cffc434fbdcb05b8e04bffcd4059cd1
Closes-Bug: #1498870
The Certificate controller has 2 operations:
1. POST
Generate X509 certificate using bay's CA cert.
Below is an example of Certificate POST API request using magnum command:
Example Request:
curl -X POST -H 'Content-Type: application/json' \
-d '{"bay_uuid": "<bay_uuid>", "csr": "<csr>"}' \
http://localhost:9511/v1/certificates
This creates a X509 certificate signed by the given bay's CA and returns
it. No database information is stored in Magnum against it. For each POST
request, a new certificate is generated.
Example Response:
{"bay_uuid": "<bay_uuid>", "csr": "<csr>",
"pem": "<pem encoded certifiacte>"}
2. GET
Fetches the CA cert associated with a bay. Below is an example of CA GET
API request using magnum command:
Example Request:
curl -X GET http://localhost:9511/v1/certificates/<bay_uuid>
This fetches stored CA cert for the given Bay, which can be used to validate
any client and node certificates signed by the Bay's CA. The value for each
is fetched from Barbican or Magnum db based on the different configuration
for storage of certificates.
Example Response:
{"bay_uuid": "<bay_uuid>", "pem": "<pem encoded certifiacte>"}
Co-Authored-By: Andrew Melton <andrew.melton@rackspace.com>
Change-Id: I4b72cc1e1bddc7a7c7eeb0ab22d3769a666ccb2b
Partially-Implements: bp secure-kubernetes
Michal Arbet