Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 20 additions & 1 deletion modules/nw-ingress-setting-a-custom-default-certificate.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -71,5 +71,24 @@ map[name:custom-certs-default]
+
The certificate secret name should match the value used to update the CR.

Your Ingress Controller now uses the custom certificate, but it is not trusted
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A procedure module shouldn't have two sets of steps like this. You could always put these steps in a note, but if it's always going to be required, then I would add these as steps 4 and 5.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This workaround is required to accomplish several other processes, so I think it makes sense to just append as steps four and five. Thanks for the tip! 😊

by the web console. You must expose your CA certificate so the Ingress
Controller can communicate with all routes.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your Ingress Controller now uses the custom certificate to secure client-side connections using TLS. Some platform components (i.e. web console) use routes for communication and therefore must trust the Ingress Controller's custom certificate. This is accomplished through the trustedCA field of the Proxy resource. The trustedCA field is a reference to a ConfigMap containing the custom certificate and key pair used by the Ingress Controller.

@Miciah @bparees a Secret is used by the router and a ConfigMap is used for cluster-wide proxy. I think it would provide a better user experience if we settled on one resource type.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we chose a configmap for trusted CA because CAs are public information that does not need to be protected.


. Configure the CA certificate as the cluster proxy certificate:
+
----
$ oc -n openshift-config create configmap custom-ca --from-file=ca-bundle.crt=example-ca.crt
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This example-ca.crt - did the user need to have created this already? Or should it be tls.crt like earlier in the procedure refers to? Or should it be a replaceable value that we tell the user to replace?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes; that should've been created already. I skipped the creation process due to the listed prerequisite assuming the user already possessed a cert:

You must have a certificate/key pair in PEM-encoded files, where the certificate is signed by a trusted certificate authority and valid for the Ingress domain.

I'm now realizing that was for the TLS cert. I'll add another prerequisite for this one.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A note should be added that if proxy is already has a trustedCA reference, the existing ConfigMap should be updated ($oc edit) to include the custom certificate instead of creating a new configmap and patching proxy/cluster.

$ oc patch proxy/cluster --type=merge --patch='{"spec":{"trustedCA":{"name":"custom-ca"}}}'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@codyhoag - @danehans would be the one to review this. It looks like from his comment [1] that there might be different steps depending on whether the cluster-wide proxy is already enabled or not. @danehans Can you confirm?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1712525#c40

----
+
. Configure the certificate as the Ingress Controller's default certificate:
+
----
$ oc -n openshift-ingress create secret tls custom-default-cert --cert=example.crt --key=example.key
$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge \
--patch='{"spec":{"defaultCertificate":{"name":"custom-default-cert"}}}'
----

Once the `IngressController` CR has been modified, the Ingress Operator
will update the Ingress Controller's deployment to use the custom certificate.
updates the Ingress Controller's deployment to use both certificates.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You may want to make make reference to $ oc get ingresscontroller/default -n openshift-ingress-operator -o yaml to verify the status of the default ingress controller after implementing the changes.