- What is the nature and description of the request? As an admin I need the ability to have control over my certificates and certificate authorities so that I can use private CAs etc. - Why does the customer need this? (List the business requirements here) So that they can use private CAs or if they need to see what CA they are using, Change the CA they are using, or add to the CA they are using. If adding a Load Balancer that is signed by a different CA, you would need to be able to add this CA's certs/keys to the .kube/config - How would the customer like to achieve this? (List the functional requirements here) Add an oc or kube command that can list/edit/modify the CAs, certificates,and keys listed in the .kube/config on each node/master. The ability to List the current features. The ability to Edit, or change, the current features. And the ability to Modify, or add to/remove from, the current features. - Is there already an existing RFE upstream or in Red Hat Bugzilla? Not that I could find - List any affected packages or components. OpenShift Kubernetes
What parts of `oc config ...` are insufficient and how could they better meet the customer's needs? Specifically `oc config set-credentials` and `oc config view`?
(In reply to Clayton Coleman from comment #2) > What parts of `oc config ...` are insufficient and how could they better > meet the customer's needs? Specifically `oc config set-credentials` and `oc > config view`? Can you show these commands would let you list/edit/modify the CAs, that a cluster are using. How can a new CA (tursted signer - not used for signing) be added / removed using thes commands?
Do we need separate RFEs for: https://bugzilla.redhat.com/show_bug.cgi?id=1293400 and https://bugzilla.redhat.com/show_bug.cgi?id=1293404 or can we roll them all into this one?
(In reply to Dan McPherson from comment #5) > Do we need separate RFEs for: > > https://bugzilla.redhat.com/show_bug.cgi?id=1293400 > and > https://bugzilla.redhat.com/show_bug.cgi?id=1293404 > > or can we roll them all into this one? We can however as they are for different request operations, it was thought to be more prudent to split them into two requests. Your call Dan.
*** Bug 1293404 has been marked as a duplicate of this bug. ***
*** Bug 1293400 has been marked as a duplicate of this bug. ***
I have marked the corresponding requests for List and Edit functionality as duplicates of this one.
*** Bug 1293399 has been marked as a duplicate of this bug. ***
One thing is missing: kube config will be regenerated.... OK.... But I guess you still will need to reinstall the router after this regeneration. The procedure is OK for a full install, but does not allows to change easily the CA without full reinstall. I would say that the trusted CA's certificates should be shared by all project and that the CA Bundle shall not be in each kubeconfig! For instance we could have a separate secret shared by all projects?
*** Bug 1367599 has been marked as a duplicate of this bug. ***
Adding the related additional requests here from 1367599: * shorter certificate expiry times with automated rotation ability (90d expiry with 30d rotation? or 28d expiry with 7d rotation?) * monitoring tools to check for imminent expiry date in case auto-rotation fails
Call out to CA Authority will be in OCP 3.6 via upstream https://github.com/kubernetes/features/issues/43
Kubernetes issue #43 seems to provide the ability to: - Generate a certificate signing request (that can be sent to a CA) - Update certificates/keys across the cluster But it does not include the ability to call out to an external service on an automated basis (see Dan McPherson's comment #16), which means it's not useful for services that require rotation on a more frequent basis. An operator will still need to manually update certificates on an annual basis. Given that #1367599 was closed as a dupe of this one, I'd expect the ability to call out to an external host before closing this RFE (or for 1367599 to be reopened).
*** Bug 1451900 has been marked as a duplicate of this bug. ***
OpenShift is not using the CSR API to set up cluster certs in 3.6 You would also have a chicken-and-egg problem using that API to set up serving certs for the API server and etcd servers
Red Hat is moving OpenShift feature requests to a new JIRA RFE system. This bz (RFE) has been identified as a feature request which is still being evaluated and has been moved. As the new Jira RFE system is not yet public, Red Hat Support can help answer your questions about your RFEs via the same support case system. https://.jira.coreos.com/browse/RFE-161
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days