Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use self-signed default router certificate #109

Conversation

Miciah
Copy link
Contributor

@Miciah Miciah commented Jan 25, 2019

Add library-go dependency

Use self-signed default router certificate

Generate a CA certificate and use it to generate default certificates for routers. Publish the CA certificate in a configmap, which can be incorporated into CA bundles in order to trust the default certificates.

This PR resolves NE-139.

  • manifests/00-cluster-role.yaml: Grant the operator create, get, list, watch, and delete access to configmaps.
  • pkg/manifests/manifests.go (RouterServiceInternal): Change serving-cert secret name so as not to conflict with the secret that the operator creates.
  • pkg/manifests/manifests_test.go (TestManifests): Adjust for the change to RouterServiceInternal.
  • pkg/operator/controller/controller.go (caCertSecretName):
    (caCertConfigMapName): New constants for the name of the secret and configmap for the CA certificate.
    (CACert): New type to hold a cached copy of the CA certificate and to keep track of the resource versions of the most recently successfully observed secret and configmap for the CA certificate.
    (Config): Add CACert field.
    (ensureRouterForIngress): Call ensureDefaultCertificateForIngress.
    (ensureDefaultCertificateForIngress): New function to check that a default certificate exists for a given ClusterIngress, and generate a certificate and create a secret for it if none exists. Use ensureRouterCACertificate to get the certificate used to sign the default certificate.
    (ensureRouterCACertificate): New function to get the CA certificate for signing default certificates, and generate a CA certificate and create a configmap and secret for it if none exists.
  • test/e2e/operator_test.go (TestRouterCACertificate): New test that gets the configmap with the CA certificate and verifies that the router's default certificate is valid using the CA certificate.

@ironcladlou, this is WIP for now because the implementation currently requires far too broad permissions for the operator.

@openshift-ci-robot openshift-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Jan 25, 2019
@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 25, 2019
@ironcladlou
Copy link
Contributor

What about storing the CA cert itself in openshift-ingress-operator and reserving openshift-ingress for resources owned by a ClusterIngress? I think this would keep the dependency graph a little cleaner and also allow the CA cert to survive the destruction of the openshift-ingress namespace.

@Miciah
Copy link
Contributor Author

Miciah commented Jan 25, 2019

What about storing the CA cert itself in openshift-ingress-operator and reserving openshift-ingress for resources owned by a ClusterIngress? I think this would keep the dependency graph a little cleaner and also allow the CA cert to survive the destruction of the openshift-ingress namespace.

Yeah, that seems reasonable. We still want to put the secret for the default certificate in openshift-ingress, so that doesn't resolve the RBAC issue.

@Miciah
Copy link
Contributor Author

Miciah commented Jan 25, 2019

/retest

@Miciah
Copy link
Contributor Author

Miciah commented Jan 25, 2019

/hold

@openshift-ci-robot openshift-ci-robot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Jan 25, 2019
@Miciah Miciah force-pushed the NE-139-use-self-signed-default-routing-certificate branch from da0cb43 to 6ef8c19 Compare January 26, 2019 03:06
@openshift-ci-robot openshift-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jan 26, 2019
@Miciah
Copy link
Contributor Author

Miciah commented Jan 26, 2019

Latest push adds a TestRouterCACertificate end-to-end test, moves the configmap with the CA certificate to the "openshift-ingress-operator" namespace, and drops configmaps access permissions from the operator's cluster role.

@Miciah Miciah force-pushed the NE-139-use-self-signed-default-routing-certificate branch from 6ef8c19 to db522b1 Compare January 26, 2019 03:27
@Miciah
Copy link
Contributor Author

Miciah commented Jan 26, 2019

/retest

1 similar comment
@Miciah
Copy link
Contributor Author

Miciah commented Jan 26, 2019

/retest

@Miciah Miciah force-pushed the NE-139-use-self-signed-default-routing-certificate branch from db522b1 to a2f816f Compare January 26, 2019 10:04
@Miciah
Copy link
Contributor Author

Miciah commented Jan 26, 2019

Latest push changes the name of the CA certificate in the router-ca configmap from tls.crt to ca-bundle.crt to match cluster-kube-apiserver-operator's expectations.

@Miciah
Copy link
Contributor Author

Miciah commented Jan 26, 2019

Fix TestRouterCACertificate for the last change.

@Miciah
Copy link
Contributor Author

Miciah commented Jan 26, 2019

/retest

@@ -8,6 +8,7 @@ rules:
- ""
resources:
- namespaces
- secrets
Copy link
Contributor

Choose a reason for hiding this comment

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

Ouch

Copy link

Choose a reason for hiding this comment

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

Yeah, but how can you get around that? That's the problem with this approach.

At least it's not the router that can read secrets.

Copy link
Contributor

Choose a reason for hiding this comment

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

True. Only way I know of to get around it is to let the CVO create the openshift-ingress namespace and a role binding in that namespace for the operator SA.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

After further discussion, we decided to defer this issue for now.

@knobunc
Copy link

knobunc commented Jan 28, 2019

@ericavonb @enj @mrogers950 FYI & please feel free to comment

@ironcladlou
Copy link
Contributor

LGTM but I'll hold off tagging until @Miciah has had a chance to comment on whether he's satisfied

return fmt.Errorf("failed to get CA certificate: %v", err)
}
hostnames := sets.NewString(fmt.Sprintf("*.%s", *ci.Spec.IngressDomain))
cert, err := ca.MakeServerCert(hostnames, 0)

Choose a reason for hiding this comment

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

Rather than a single creation of the CA and cert, you should use the library-go certificate rotators. You'll get creation and rotation on both for free.

CA rotator example:
https://github.com/openshift/cluster-kube-apiserver-operator/blob/master/pkg/operator/certrotationcontroller/certrotationcontroller.go#L150

Server cert rotator example: https://github.com/openshift/cluster-kube-apiserver-operator/blob/master/pkg/operator/certrotationcontroller/certrotationcontroller.go#L175

Copy link
Contributor Author

@Miciah Miciah Jan 28, 2019

Choose a reason for hiding this comment

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

@mrogers950, thanks for the pointer! It looks like certrotationcontroller is designed to handle a single server certificate whereas we want to have one per router. Does library-go have something we can use to manage multiple server certifcates, or will it only work for the signing certificate and bundle? Anyway, certificate rotation is descoped for 4.0, so I'll add a TODO.

Choose a reason for hiding this comment

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

Yeah, right now there's one client+server+CA set per controller, so you would need one controller per router.

assets/router/deployment.yaml Outdated Show resolved Hide resolved
pkg/manifests/manifests_test.go Outdated Show resolved Hide resolved
@Miciah
Copy link
Contributor Author

Miciah commented Jan 28, 2019

Latest push squashes the RBAC change into the main commit; removes the metrics-certs secret, volume, and environment variables; and adds a TODO to use certrotationcontroller.

@Miciah Miciah force-pushed the NE-139-use-self-signed-default-routing-certificate branch from 4fa14e3 to 6b9ab0a Compare January 28, 2019 21:09
@Miciah Miciah changed the title [WIP] Use self-signed default router certificate Use self-signed default router certificate Jan 28, 2019
@openshift-ci-robot openshift-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 28, 2019
Generate a CA certificate and use it to generate default certificates for
routers.  Publish the CA certificate in a configmap, which can be
incorporated into CA bundles in order to trust the default certificates.

This commit resolves NE-139.

https://jira.coreos.com/browse/NE-139

* manifests/00-cluster-role.yaml: Grant the operator create, get, list,
watch, and delete access to secrets.
* pkg/manifests/manifests.go (RouterServiceInternal): Change serving-cert
secret name so as not to conflict with the secret that the operator
creates.
* pkg/manifests/manifests_test.go (TestManifests): Adjust for the change to
RouterServiceInternal.
* pkg/operator/controller/controller.go (caCertSecretName):
(caCertConfigMapName): New constants for the name of the secret and
configmap for the CA certificate.
(CACert): New type to hold a cached copy of the CA certificate and to keep
track of the resource versions of the most recently successfully observed
secret and configmap for the CA certificate.
(Config): Add CACert field.
(ensureRouterForIngress): Call ensureDefaultCertificateForIngress.
(ensureDefaultCertificateForIngress): New function to check that a default
certificate exists for a given ClusterIngress, and generate a certificate
and create a secret for it if none exists.  Use ensureRouterCACertificate
to get the certificate used to sign the default certificate.
(ensureRouterCACertificate): New function to get the CA certificate for
signing default certificates, and generate a CA certificate and create a
configmap and secret for it if none exists.
* test/e2e/operator_test.go (TestRouterCACertificate): New test that gets
the configmap with the CA certificate and verifies that the router's
default certificate is valid using the CA certificate.
@Miciah Miciah force-pushed the NE-139-use-self-signed-default-routing-certificate branch from 6b9ab0a to 228c9b3 Compare January 28, 2019 22:17
@Miciah
Copy link
Contributor Author

Miciah commented Jan 28, 2019

Latest push changes the annotation on the internal router service so the serving-cert signer will not stomp the secret that the operator creates.

@Miciah
Copy link
Contributor Author

Miciah commented Jan 29, 2019

/retest

@ironcladlou
Copy link
Contributor

/hold cancel

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 29, 2019
@ironcladlou
Copy link
Contributor

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jan 29, 2019
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ironcladlou, Miciah

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants