-
Notifications
You must be signed in to change notification settings - Fork 88
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 internal-encryption
to deploy internal certificates automatically
#855
Use internal-encryption
to deploy internal certificates automatically
#855
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: nak3 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 |
Codecov Report
@@ Coverage Diff @@
## main #855 +/- ##
==========================================
- Coverage 81.83% 81.39% -0.44%
==========================================
Files 18 18
Lines 1167 1172 +5
==========================================
- Hits 955 954 -1
- Misses 168 174 +6
Partials 44 44
Continue to review full report at Codecov.
|
@nak3 pls rebase. |
@skonto This also needs knative/networking#680. |
@@ -63,6 +63,10 @@ const ( | |||
// disableHTTP2AnnotationKey is the annotation key attached to a Knative Domain Mapping | |||
// to indicate that http2 should not be enabled for it. | |||
disableHTTP2AnnotationKey = "kourier.knative.dev/disable-http2" | |||
|
|||
// ServingNamespaceEnv is an env variable specifying where the serving is deployed. | |||
// e.g. OpenShift deploys Kourier in different namespace so `system.Namespace()` does not work. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Afaik this holds for backwards compatibility reasons. Would it be possible in the future to move everything to serving
ns?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is possible but it has a lot of risks to move the gateway into serving ns.
@skonto Could you please take a look? |
@@ -313,7 +310,7 @@ func createUpstreamTLSContext(caCertificate []byte, activatorSAN string, alpnPro | |||
}, | |||
MatchSubjectAltNames: []*envoymatcherv3.StringMatcher{{ | |||
MatchPattern: &envoymatcherv3.StringMatcher_Exact{ | |||
Exact: activatorSAN, | |||
Exact: certificates.FakeDnsName, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess if we ever have multiple-knative installations this will have to be changed?
/lgtm /hold for @evankanderson for any additional comments. |
Since knative-extensions/net-kourier#855, kourier controller supports SERVING_NAMESPACE env value to specify the serving namespace. The feature is required when internal encryption is supported.
This patch is same purpose with knative/serving#13005.
Currently users have to deploy certificates manually with several options such as
activator-san
,activator-ca
,queue-proxy-ca
etc.Such deployment and management of the certificates is a big burden for users.