BackendTLSPolicy and RBAC/persona model

[mkosieradzki]

Hi there,

During discussion in PR: #3180 (comment), I started to wonder how does the BackendTLSPolicy fit the persona model.

https://gateway-api.sigs.k8s.io/concepts/security-model/#rbac doesn't mention BackendTLSPolicy or any policy resources explicitly, intuitively I would associate it with Ian or Chichiro, while the current experiment proposal seems to associate it with Ana, as per: https://gateway-api.sigs.k8s.io/api-types/backendtlspolicy/

The BackendTLSPolicy and the Service must reside in the same namespace in order to prevent the complications involved with sharing trust across namespace boundaries.

What would be the correct persona for BackendTLSPolicy and should it reside in the same namespace as service?

[robscott]

I tend to agree with you that BackendTLSPolicy should not be owned by Ana (the App Dev). BackendTLSPolicy defines:

1. How the Gateway should validate the certs provided by the backend
2. Which SNI the Gateway should use to connect to the backend
3. [Maybe] The client certificate that a Gateway should use when connecting to a backend

I think that 1 should be controlled by the Gateway owner (Chihiro), and the exception is just that in some rare cases we'll need per-Service configuration for this, not that the App Owner should be the one that owns this piece.

In my opinion, 2 is something that is very likely to be unique per application, though could be shared across multiple overlapping Services (foo, foo-v1, foo-v2). It likely makes sense for Ana to be the one to configure this.

I think that 3 is very similar to 1 in terms of ownership (Chihiro/Gateway owner + room for per-Service overrides). I think this largely matches what others have already been saying in #3180.

So let's summarize that in a table:

Use Case	Primary Owner	Conditional Override?
1. Backend cert validation	Chihiro (Gateway owner)	Per-Service, still Chihiro
2. SNI	Ana (App owner)	Maybe a default format/template that is defined by API spec and/or Chihiro?
3. Client Certificate	Chihiro (Gateway owner)	Per-Service, still Chihiro

I think I had this high level idea when I suggested that we may want to specify BackendTLS validation config at a Gateway level in the TLS memorandum GEP.

In the context of #3180, I think it's clear that we should start with Gateway-level config, but this is also highlighting that BackendTLSPolicy may not be clearly aligned with personas, and we should revisit that before we try to push it to GA.

/cc @candita @youngnick

[candita]

@robscott I have a different perspective on BackendTLSPolicy caretakers.

I envisioned the app developer as the one who generated and managed the certificates used in BackendTLSPolicy, freeing the cluster admin from having to generate/manage certificates that should be owned by the app developer. We discussed this early on, that cluster admins do not want to generate/manage application-related certificates. Since the app developer is also the owner of the xRoute used, they would need to manage the SNI and of course need the SNI for generating/updating the certificates.

From the BackendTLSPolicy GEP, goal 2:

In terms of the Gateway API personas, only the application developer persona applies in this solution. The application developer should control the gateway to backend TLS settings, not the cluster operator, as requiring a cluster operator to manage certificate renewals and revocations would be extremely cumbersome.

If it's really a matter of opinion/perspective, would it be better to make it a multi-role component, or better to discuss the pros and cons of choosing a single role?

[youngnick]

I agree with @candita here, my conception was always that this is about allowing Ana to self-manage TLS details (or have them managed on her behalf by some controller).

So it's Ana who defines the CA to use, and the SNI (because I assumed that most uses of BackendTLSPolicy will probably be using a self-signed CA that is not part of the global trust chain, so it's necessary for Ana to provide the CA as well).

BackendTLSPolicy is originally designed to handle the use case of "we have a requirement for all traffic to be TLS in-transit, but Ana needs to handle her own TLS".