Extra minimal OCG API #3952
Extra minimal OCG API #3952
Conversation
k8s-ci-robot
added
release-note-none
k8s-ci-robot
added
do-not-merge/hold
| - The trust bundle | ||
| in the Gateway resource | ||
| will define the CA certificate(s) | ||
| that the OCG | ||
| should accept as trusted | ||
| when validating connections | ||
| from meshed peers. | ||
|
|
||
| - The trust bundle | ||
| in the Mesh resource | ||
| will define the CA certificate(s) | ||
| that the mesh | ||
| should accept as trusted | ||
| when validating connections | ||
| from the OCG. |
There was a problem hiding this comment.
can we add a bit more info around why we chose to have GW trust bundle and mesh and the Mesh trust bundle in the GW resource?
while i agree that this model to be simpler, but IMO it's worth mentioning the alternatives.
i added some info around this in https://github.com/kubernetes-sigs/gateway-api/pull/3941/files#diff-4a7d8011b2ad7222ce2d13ee98f49443d6eb56518625438daa62c10e94d9f772R279-R489
specifically proposals 1 and 2.
There was a problem hiding this comment.
with the proposed model, is the mesh trust bundle duplicated every single Gateway resource?
(is there a common gateway config somewhere?)
There was a problem hiding this comment.
The proposed model is that each Gateway gets its own trust bundle. We may want to consider having a default in the GatewayClass, but this is the extra minimal API so it's not there yet.
There was a problem hiding this comment.
And I agree about alternatives -- I had it in my head that in many cases I should move them into GEP-3792 itself, but thinking about it while the sun is up, that seems silly. 🙂 Will update.
| trustBundle: | ||
| name: mesh-trust-bundle | ||
| namespace: mesh-namespace | ||
| # Key in Configmap; defaults to "ca-bundle.crt" | ||
| bundleKey: ca-bundle.crt |
There was a problem hiding this comment.
i personally think clusterTrustBundle is a good fit for this. can we mention that we intend to support clusterTrustBundle in the future? or do u see some fundamental problem with it?
There was a problem hiding this comment.
+1, I'd much rather start with ClusterTrustBundle as the recommendation where available, and ConfigMap as an optional backfill where it's not. I know that's not great now, but by the time this API is stable/GA, I'm guessing ClusterTrustBundle will be much more widely available.
| matchLabels: | ||
| mesh: one-mesh-to-mesh-them-all |
There was a problem hiding this comment.
just to confirm - is this selecting the Mesh resource or the Routes or Namespaces?
i think it's the latter but the one-mesh-to-mesh-them-all is confusing me because u have that set on the Mesh resource in the Mesh GEP.
also, can u consider calling out some alternative mechanisms?
https://github.com/kubernetes-sigs/gateway-api/pull/3941/files#diff-4a7d8011b2ad7222ce2d13ee98f49443d6eb56518625438daa62c10e94d9f772R638-R730.
doesn't have to be this but i think it's useful to document the alternatives.
There was a problem hiding this comment.
If lines 142-144 are still the state, it looks like this selects Routes. Left another comment on those lines. And also we had a different comment thread on the original PR.
My strong preference is to go with namespace, and potentially provide opt-out for services.
| The extra-minimal API | ||
| solves this problem | ||
| by adding a label selector | ||
| to the Gateway resource | ||
| that indicates which Routes | ||
| are meshed. | ||
| When the OCG connects | ||
| to any Route | ||
| that either directly matches this selector, | ||
| or is in a namespace that matches this selector, | ||
| it MUST use mTLS | ||
| with a certificate | ||
| that is ultimately signed | ||
| by a CA certificate | ||
| in the Mesh resource's `trustBundle`, | ||
| and the OCG MUST validate | ||
| that the peer presents a certificate | ||
| that is ultimately signed | ||
| by a CA certificate | ||
| in the Gateway resource's `trustBundle`. |
There was a problem hiding this comment.
couple of open questions (copied from my #3941) :
- How to configure the Gateway's identity certificate and private key?
This GEP defines how the OCG and the mesh should be configured to trust each
other by exchanging CA bundles. However, it does not standardize how an
administrator configures the specific client certificate and private key that
the OCG uses to identify itself to the mesh.
Currently, this is left as an implementation detail, likely handled via a
provider-specific CRD referenced from the GatewayClass or through an out-of-band
mechanism. The open question is: Should a future version of this GEP standardize
this configuration to ensure a consistent user experience? This could involve
adding a new identityCertificateRef field to the Gateway spec.
- Should use cases where mesh workloads disable mTLS be supported?
This GEP focuses on meshes where mTLS is strictly enforced for
communication. However, some service meshes support a "DISABLE" mode where mTLS
can be disabled for certain workloads. This raises the question: How should an
OCG behave when a target workload is discovered as "meshed" but does not require
or accept an mTLS connection?
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: kflynn The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
needs-rebase
Signed-off-by: Flynn <[email protected]>
Signed-off-by: Flynn <[email protected]>
Signed-off-by: Flynn <[email protected]>
k8s-ci-robot
removed
the
needs-rebase
|
@kflynn: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
| [GEP-3792] defines the rationale | ||
| for allowing out-of-cluster Gateways (OCGs) | ||
| to participate in a | ||
| GAMMA-compliant in-cluster service mesh, | ||
| and the problems that must be solved | ||
| to allow them to do so. | ||
| This GEP defines | ||
| an extremely minimal API | ||
| to permit experimentation | ||
| with OCGs and | ||
| in-cluster mTLS meshes. |
There was a problem hiding this comment.
This is odd formatting? is this a new formatter or something?
| - a `labelSelector` field | ||
| that indicates which Routes | ||
| are meshed. |
There was a problem hiding this comment.
I think we had similar comment thread on the original PR. #3894 (comment)
I am unclear why we need to select routes, namespace seems like it would cover 90% of the cases, and we can opt-in OR opt-out services.
| matchLabels: | ||
| mesh: one-mesh-to-mesh-them-all |
There was a problem hiding this comment.
If lines 142-144 are still the state, it looks like this selects Routes. Left another comment on those lines. And also we had a different comment thread on the original PR.
My strong preference is to go with namespace, and potentially provide opt-out for services.
This is a GEP for an extra minimal OCG API, intended not to be production-ready but to permit experimentation.
/kind gep
Fixes #3951