-
Notifications
You must be signed in to change notification settings - Fork 77
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
Add internal trust flag to config #778
Conversation
Signed-off-by: David Hadas <david.hadas@gmail.com>
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #778 +/- ##
==========================================
- Coverage 94.80% 94.57% -0.23%
==========================================
Files 41 41
Lines 1231 1253 +22
==========================================
+ Hits 1167 1185 +18
- Misses 52 56 +4
Partials 12 12
☔ View full report in Codecov by Sentry. |
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'm going to continue to object to the idea that verifying a server SAN and CA does not provide MITM protection, but I'm happy to enable the internal-trust
boolean for future mutual TLS.
config/config-network.yaml
Outdated
# NOTE: This flag is in an alpha state and is mostly here to enable internal testing | ||
# for now. Use with caution. | ||
internal-encryption: "false" | ||
_example: "################################\n# #\n# EXAMPLE CONFIGURATION #\n# #\n################################\n\n# This block is not actually functional configuration,\n# but serves to illustrate the available configuration\n# options and document them in a way that is accessible\n# to users that `kubectl edit` this config map.\n#\n# These sample configuration options may be copied out of\n# this example block and unindented to be in the data block\n# to actually change the configuration.\n\n# ingress-class specifies the default ingress class\n# to use when not dictated by Route annotation.\n#\n# If not specified, will use the Istio ingress.\n#\n# Note that changing the Ingress class of an existing Route\n# will result in undefined behavior. Therefore it is best to only\n# update this value during the setup of Knative, to avoid getting\n# undefined behavior.\ningress-class: \"istio.ingress.networking.knative.dev\"\n\n# certificate-class specifies the default Certificate class\n# to use when not dictated by Route annotation.\n#\n# If not specified, will use the Cert-Manager Certificate.\n#\n# Note that changing the Certificate class of an existing Route\n# will result in undefined behavior. Therefore it is best to only\n# update this value during the setup of Knative, to avoid getting\n# undefined behavior.\ncertificate-class: \"cert-manager.certificate.networking.knative.dev\"\n\n# namespace-wildcard-cert-selector specifies a LabelSelector which\n# determines which namespaces should have a wildcard certificate\n# provisioned.\n#\n# Use an empty value to disable the feature (this is the default):\n# namespace-wildcard-cert-selector: \"\"\n#\n# Use an empty object to enable for all namespaces\n# namespace-wildcard-cert-selector: {}\n#\n# Useful labels include the \"kubernetes.io/metadata.name\" label to\n# avoid provisioning a certifcate for the \"kube-system\" namespaces.\n# Use the following selector to match pre-1.0 behavior of using\n# \"networking.knative.dev/disableWildcardCert\" to exclude namespaces:\n#\n# matchExpressions:\n# - key: \"networking.knative.dev/disableWildcardCert\"\n# operator: \"NotIn\"\n# values: [\"true\"]\nnamespace-wildcard-cert-selector: \"\"\n\n# domain-template specifies the golang text template string to use\n# when constructing the Knative service's DNS name. The default\n# value is \"{{.Name}}.{{.Namespace}}.{{.Domain}}\".\n#\n# Valid variables defined in the template include Name, Namespace, Domain,\n# Labels, and Annotations. Name will be the result of the tagTemplate\n# below, if a tag is specified for the route.\n#\n# Changing this value might be necessary when the extra levels in\n# the domain name generated is problematic for wildcard certificates\n# that only support a single level of domain name added to the\n# certificate's domain. In those cases you might consider using a value\n# of \"{{.Name}}-{{.Namespace}}.{{.Domain}}\", or removing the Namespace\n# entirely from the template. When choosing a new value be thoughtful\n# of the potential for conflicts - for example, when users choose to use\n# characters such as `-` in their service, or namespace, names.\n# {{.Annotations}} or {{.Labels}} can be used for any customization in the\n# go template if needed.\n# We strongly recommend keeping namespace part of the template to avoid\n# domain name clashes:\n# eg. '{{.Name}}-{{.Namespace}}.{{ index .Annotations \"sub\"}}.{{.Domain}}'\n# and you have an annotation {\"sub\":\"foo\"}, then the generated template\n# would be {Name}-{Namespace}.foo.{Domain}\ndomain-template: \"{{.Name}}.{{.Namespace}}.{{.Domain}}\"\n\n# tagTemplate specifies the golang text template string to use\n# when constructing the DNS name for \"tags\" within the traffic blocks\n# of Routes and Configuration. This is used in conjunction with the\n# domainTemplate above to determine the full URL for the tag.\ntag-template: \"{{.Tag}}-{{.Name}}\"\n\n# Controls whether TLS certificates are automatically provisioned and\n# installed in the Knative ingress to terminate external TLS connection.\n# 1. Enabled: enabling auto-TLS feature.\n# 2. Disabled: disabling auto-TLS feature.\nauto-tls: \"Disabled\"\n\n# Controls the behavior of the HTTP endpoint for the Knative ingress.\n# It requires autoTLS to be enabled.\n# 1. Enabled: The Knative ingress will be able to serve HTTP connection.\n# 2. Redirected: The Knative ingress will send a 301 redirect for all\n# http connections, asking the clients to use HTTPS.\n#\n# \"Disabled\" option is deprecated.\nhttp-protocol: \"Enabled\"\n\n# rollout-duration contains the minimal duration in seconds over which the\n# Configuration traffic targets are rolled out to the newest revision.\nrollout-duration: \"0\"\n\n# autocreate-cluster-domain-claims controls whether ClusterDomainClaims should\n# be automatically created (and deleted) as needed when DomainMappings are\n# reconciled.\n#\n# If this is \"false\" (the default), the cluster administrator is\n# responsible for creating ClusterDomainClaims and delegating them to\n# namespaces via their spec.Namespace field. This setting should be used in\n# multitenant environments which need to control which namespace can use a\n# particular domain name in a domain mapping.\n#\n# If this is \"true\", users are able to associate arbitrary names with their\n# services via the DomainMapping feature.\nautocreate-cluster-domain-claims: \"false\"\n\n# If true, networking plugins can add additional information to deployed\n# applications to make their pods directly accessible via their IPs even if mesh is\n# enabled and thus direct-addressability is usually not possible.\n# Consumers like Knative Serving can use this setting to adjust their behavior\n# accordingly, i.e. to drop fallback solutions for non-pod-addressable systems.\n#\n# NOTE: This flag is in an alpha state and is mostly here to enable internal testing\n# for now. Use with caution.\nenable-mesh-pod-addressability: \"false\"\n\n# mesh-compatibility-mode indicates whether consumers of network plugins\n# should directly contact Pod IPs (most efficient), or should use the\n# Cluster IP (less efficient, needed when mesh is enabled unless\n# `enable-mesh-pod-addressability`, above, is set).\n# Permitted values are:\n# - \"auto\" (default): automatically determine which mesh mode to use by trying Pod IP and falling back to Cluster IP as needed.\n# - \"enabled\": always use Cluster IP and do not attempt to use Pod IPs.\n# - \"disabled\": always use Pod IPs and do not fall back to Cluster IP on failure.\nmesh-compatibility-mode: \"auto\"\n\n# Defines the scheme used for external URLs if autoTLS is not enabled.\n# This can be used for making Knative report all URLs as \"HTTPS\" for example, if you're\n# fronting Knative with an external loadbalancer that deals with TLS termination and\n# Knative doesn't know about that otherwise.\ndefault-external-scheme: \"http\"\n\n# internal-encryption indicates whether internal traffic is encrypted or not.\n# Using internal-encryption does not protect against MITM attacks\n# If this is \"true\", the following traffic are encrypted:\n# - ingress to activator\n# - ingress to queue-proxy\n# - activator to queue-proxy\n#\n# NOTE: This flag is in an alpha state and is mostly here to enable internal testing\n# for now. Use with caution.\ninternal-encryption: \"false\"\n\n# internal-trust indicates whether internal traffic is encrypted and mutual trust is achieved.\n# Using internal-trust protect against MITM attacks and ensures that all requests received\n# will go via the ingress and will come from an approved set of sources \n# (e.g. KServ from recognized namespaces)\n# If this is \"true\", the following traffic is encrypted and client authentication is verified with mutual TLS:\n# - ingress to activator\n# - ingress to queue-proxy\n# - activator to queue-proxy\n#\n# NOTE: This flag is in an alpha state and is mostly here to enable internal testing\n# for now. Use with caution.\ninternal-trust: \"false\"\n" |
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.
This got corrupted to containing internal newlines...
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.
yes, I am trying to recover
the yaml lint failure is due to too many fixer warning which will be fixed once this knative/actions#120 lands. The golang linter, I have no idea why it is checking other files not being changed, my local test krsna-m#1 does not have that issue. |
I changed the file that is being reported - but the warnings are not in the lines changed. |
/retest |
1 similar comment
/retest |
/hold |
/retest |
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'm being picky about names because these are presumably going to be interfaces that administrators will continue to use for years.
I'm 👍 on the general intent of this change at this point.
config/config-network.yaml
Outdated
# internal-trust = "identity" same as "mutual" and also adds sender identity verified by the Kingress and forwarded to Kserv | ||
# | ||
# NOTE: This flag is in an alpha state and is mostly here to enable internal testing for now. Use with caution. | ||
internal-trust: "none" |
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'm not sure that "trust" is the right word here -- maybe you mean "internal-auth" or "internal-verification"? We're establishing trust, but the variable name could also be seen as declaring trust without an enforcement mechanism.
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'm not sure that "trust" is the right word here -- maybe you mean "internal-auth" or "internal-verification"? We're establishing trust, but the variable name could also be seen as declaring trust without an enforcement mechanism.
It is ok to change trust, but it seems better than auth even verification.
since it is suggested to control if we use any description and if we do use encryption, then, verifications do we do.
pkg/config/config.go
Outdated
@@ -295,6 +304,7 @@ func NewConfigFromMap(data map[string]string) (*Config, error) { | |||
cm.AsBool(EnableMeshPodAddressabilityKey, &nc.EnableMeshPodAddressability), | |||
cm.AsString(DefaultExternalSchemeKey, &nc.DefaultExternalScheme), | |||
cm.AsBool(InternalEncryptionKey, &nc.InternalEncryption), | |||
cm.AsString(InternalTrustKey, &nc.InternalTrust), |
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.
Not your fault, but I wish we had AsEnum
here.
(Don't take action on this gripe in this PR)
/unhold |
/assign nak3 |
config/config-network.yaml
Outdated
# internal-controlplane-trust = "mutual" ensures control messages are encrypted using mTLS (client and server authenticate each other) | ||
# | ||
# NOTE: This flag is in an alpha state and is mostly here to enable internal testing for now. Use with caution. | ||
internal-controlplane-trust: "disabled" |
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 think I understood about internal-dataplane-trust
but I am still not sure how internal-controlplane-trust
will be used. Could you share the link docs or github issue for your design/idea where I can refer to?
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.
@nak3
AFAIK, we have little on this right now.
We understand that we need to start building control plane trust (after we complete the more critical data plane trust)
And we define a flag that will allow the introduction of such work moving forward.
The little we do have is now summarized in https://docs.google.com/document/d/19R0YOBAZfed2bl99-fdUnQ89cz3hoPY6KJNxhn6b40A/edit#heading=h.n8a530nnrb - which is incomplete and need more contributions.
config/config-network.yaml
Outdated
# | ||
# NOTE: This flag is in an alpha state and is mostly here to enable internal testing | ||
# for now. Use with caution. | ||
internal-encryption: "false" | ||
|
||
# internal-dataplane-trust indicates the level of trust established in the knative data-plane. |
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.
@davidhadas @evankanderson
Do we need internal-
prefix for internal-controlplane-trust
and internal-dataplane-trust
?
I feel controlplane-trust
and dataplane-trust
are enough and they implicate "internal".
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 am ok with removing 'internal',
I was following the original internal-encryption flag.
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: davidhadas, 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 |
Fixes #777