TargetRefs identifies an API object to apply the policy to.
Note that this config applies to the entire referenced resource
by default, but this default may change in the future to provide
a more granular application of the policy.
TargetRefs must be _distinct_. This means either that:
* They select different targets. If this is the case, then targetRef
entries are distinct. In terms of fields, this means that the
multi-part key defined by `group`, `kind`, and `name` must
be unique across all targetRef entries in the BackendTLSPolicy.
* They select different sectionNames in the same target.
When more than one BackendTLSPolicy selects the same target and
sectionName, implementations MUST determine precedence using the
following criteria, continuing on ties:
* The older policy by creation timestamp takes precedence. For
example, a policy with a creation timestamp of "2021-07-15
01:02:03" MUST be given precedence over a policy with a
creation timestamp of "2021-07-15 01:02:04".
* The policy appearing first in alphabetical order by {namespace}/{name}.
For example, a policy named `foo/bar` is given precedence over a
policy named `foo/baz`.
For any BackendTLSPolicy that does not take precedence, the
implementation MUST ensure the `Accepted` Condition is set to
`status: False`, with Reason `Conflicted`.
Implementations SHOULD NOT support more than one targetRef at this
time. Although the API technically allows for this, the current guidance
for conflict resolution and status handling is lacking. Until that can be
clarified in a future release, the safest approach is to support a single
targetRef.
Support Levels:
* Extended: Kubernetes Service referenced by HTTPRoute backendRefs.
* Implementation-Specific: Services not connected via HTTPRoute, and any
other kind of backend. Implementations MAY use BackendTLSPolicy for:
- Services not referenced by any Route (e.g., infrastructure services)
- Gateway feature backends (e.g., ExternalAuth, rate-limiting services)
- Service mesh workload-to-service communication
- Other resource types beyond Service
Implementations SHOULD aim to ensure that BackendTLSPolicy behavior is consistent,
even outside of the extended HTTPRoute -(backendRef) -> Service path.
They SHOULD clearly document how BackendTLSPolicy is interpreted in these
scenarios, including:
- Which resources beyond Service are supported
- How the policy is discovered and applied
- Any implementation-specific semantics or restrictions
Note that this config applies to the entire referenced resource
by default, but this default may change in the future to provide
a more granular application of the policy.
group
string required
Group is the group of the target resource.
pattern: ^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$
kind
string required
Kind is kind of the target resource.
pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$
name
string required
Name is the name of the target resource.
sectionName
string
SectionName is the name of a section within the target resource. When
unspecified, this targetRef targets the entire resource. In the following
resources, SectionName is interpreted as the following:
* Gateway: Listener name
* HTTPRoute: HTTPRouteRule name
* Service: Port name
If a SectionName is specified, but does not exist on the targeted object,
the Policy must fail to attach, and the policy implementation should record
a `ResolvedRefs` or similar Condition in the Policy's status.
pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$