(Extracted from #14566)

This improves the injector logic by accounting for ports exposed in native sidecar containers:

- when consuming the `config.linkerd.io/opaque-ports` annotations
  pointing to (named or integer) ports in init containers
- when populating the proxy's `LINKERD2_PROXY_INBOUND_PORTS` env var

The `webhook_tests.go` have been expanded to test injection to a pod
with a memcached native sidecar container (never mind the contrivedness
of the example).

…ck --proxy`

(Extracted from #14566)

The "opaque ports are properly annotated" check had a bug where it only
validated regular containers, missing ports in init containers (native
sidecars). This meant mismatched annotations between pods and services
could go undetected when the port belonged to an init container.

When a service had the opaque-ports annotation but the corresponding pod
did not, the check would incorrectly pass if the port was defined in an
init container instead of a regular container.

This commit extends the check to validate ports in both regular containers
and init containers, ensuring consistent opaque-ports annotations across
pods and services regardless of where the port is defined.

…ck --proxy`

(Extracted from #14566)

The "opaque ports are properly annotated" check had a bug where it only
validated regular containers, missing ports in init containers (native
sidecars). This meant mismatched annotations between pods and services
could go undetected when the port belonged to an init container.

When a service had the opaque-ports annotation but the corresponding pod
did not, the check would incorrectly pass if the port was defined in an
init container instead of a regular container.

This commit extends the check to validate ports in both regular containers
and init containers, ensuring consistent opaque-ports annotations across
pods and services regardless of where the port is defined.

(Extracted from #14566)

The logic behind the `linkerd authz` command wasn't accounting for ports
in init containers, so authorization policies pointing to those ports
were not reported by the command.

Say for example you had a strict auth policy for the `linkerd-admin`
port, allowing only access from prometheus. For emojivoto's web workload
you could set that up like this:

```yaml
apiVersion: policy.linkerd.io/v1beta3
kind: Server
metadata:
  annotations:
  name: admin
  namespace: emojivoto
spec:
  accessPolicy: deny
  podSelector:
    matchLabels:
      app: web-svc
  port: linkerd-admin
  proxyProtocol: HTTP/1
---
apiVersion: policy.linkerd.io/v1alpha1
kind: MeshTLSAuthentication
metadata:
  namespace: emojivoto
  name: prometheus
spec:
  identities:
  - "prometheus.linkerd-viz.serviceaccount.identity.linkerd.cluster.local"
---
apiVersion: policy.linkerd.io/v1alpha1
kind: AuthorizationPolicy
metadata:
  namespace: emojivoto
  name: web-http-sa
spec:
  targetRef:
    group: policy.linkerd.io
    kind: Server
    name: admin
  requiredAuthenticationRefs:
    - name: prometheus
      kind: MeshTLSAuthentication
      group: policy.linkerd.io
```

Invoking `linkerd authz` would return nothing, but after this change we
can see the auth:

```
$ linkerd authz -n emojivoto deploy/web
ROUTE   SERVER  AUTHORIZATION_POLICY   SERVER_AUTHORIZATION
*       admin   web-http-sa
```

…hz` (#14780)

(Extracted from #14566)

The logic behind the `linkerd authz` command wasn't accounting for ports
in init containers, so authorization policies pointing to those ports
were not reported by the command.

Say for example you had a strict auth policy for the `linkerd-admin`
port, allowing only access from prometheus. For emojivoto's web workload
you could set that up like this:

```yaml
apiVersion: policy.linkerd.io/v1beta3
kind: Server
metadata:
  annotations:
  name: admin
  namespace: emojivoto
spec:
  accessPolicy: deny
  podSelector:
    matchLabels:
      app: web-svc
  port: linkerd-admin
  proxyProtocol: HTTP/1
---
apiVersion: policy.linkerd.io/v1alpha1
kind: MeshTLSAuthentication
metadata:
  namespace: emojivoto
  name: prometheus
spec:
  identities:
  - "prometheus.linkerd-viz.serviceaccount.identity.linkerd.cluster.local"
---
apiVersion: policy.linkerd.io/v1alpha1
kind: AuthorizationPolicy
metadata:
  namespace: emojivoto
  name: web-http-sa
spec:
  targetRef:
    group: policy.linkerd.io
    kind: Server
    name: admin
  requiredAuthenticationRefs:
    - name: prometheus
      kind: MeshTLSAuthentication
      group: policy.linkerd.io
```

Invoking `linkerd authz` would return nothing, but after this change we
can see the auth:

```
$ linkerd authz -n emojivoto deploy/web
ROUTE   SERVER  AUTHORIZATION_POLICY   SERVER_AUTHORIZATION
*       admin   web-http-sa
```

…ck --proxy` (#14779)

(Extracted from #14566)

The "opaque ports are properly annotated" check had a bug where it only
validated regular containers, missing ports in init containers (native
sidecars). This meant mismatched annotations between pods and services
could go undetected when the port belonged to an init container.

When a service had the opaque-ports annotation but the corresponding pod
did not, the check would incorrectly pass if the port was defined in an
init container instead of a regular container.

This commit extends the check to validate ports in both regular containers
and init containers, ensuring consistent opaque-ports annotations across
pods and services regardless of where the port is defined.

(Extracted from #14566)

This improves the injector logic by accounting for ports exposed in native sidecar containers:

- when consuming the `config.linkerd.io/opaque-ports` annotations
  pointing to (named or integer) ports in init containers
- when populating the proxy's `LINKERD2_PROXY_INBOUND_PORTS` env var

The `webhook_tests.go` have been expanded to test injection to a pod
with a memcached native sidecar container (never mind the contrivedness
of the example).

Those types of ports were getting ignored in `getProfile` responses. A
new test case was added that clarifies an example, that wouldn't pass
before this fix.

(Extracted from #14566)

)

Those types of ports were getting ignored in `getProfile` responses. A
new test case was added that clarifies an example, that wouldn't pass
before this fix.

(Extracted from #14566)

…etProfile

(Extracted from #14566)

When hitting pods directly at their their IPs, ports in native sidecars
that were marked as opaque via the `config.linkerd.io/opaque-ports`
annotation, weren't really being marked as opaque.

More concretely, the issue layed in the getProfile API, that was
forgoing init containers when iterating over containers in this
particular case.

Endpoint profile translator tests got expanded, testing for opaque ports
in both init and regular containers.

…etProfile (#14791)

(Extracted from #14566)

When hitting pods directly at their their IPs, ports in native sidecars
that were marked as opaque via the `config.linkerd.io/opaque-ports`
annotation, weren't really being marked as opaque.

More concretely, the issue layed in the getProfile API, that was
forgoing init containers when iterating over containers in this
particular case.

Endpoint profile translator tests got expanded, testing for opaque ports
in both init and regular containers.

(Extracted from #14566)

The `Get` API wasn't surfacing ports marked as opaque in Servers, when:

1. ports belonged to a native sidecar (inside an init container)
2. port was referred to by name

Also changed a test fixture to use port name instead of number in order
to test this issue.

…hz` (linkerd#14780)

(Extracted from linkerd#14566)

The logic behind the `linkerd authz` command wasn't accounting for ports
in init containers, so authorization policies pointing to those ports
were not reported by the command.

Say for example you had a strict auth policy for the `linkerd-admin`
port, allowing only access from prometheus. For emojivoto's web workload
you could set that up like this:

```yaml
apiVersion: policy.linkerd.io/v1beta3
kind: Server
metadata:
  annotations:
  name: admin
  namespace: emojivoto
spec:
  accessPolicy: deny
  podSelector:
    matchLabels:
      app: web-svc
  port: linkerd-admin
  proxyProtocol: HTTP/1
---
apiVersion: policy.linkerd.io/v1alpha1
kind: MeshTLSAuthentication
metadata:
  namespace: emojivoto
  name: prometheus
spec:
  identities:
  - "prometheus.linkerd-viz.serviceaccount.identity.linkerd.cluster.local"
---
apiVersion: policy.linkerd.io/v1alpha1
kind: AuthorizationPolicy
metadata:
  namespace: emojivoto
  name: web-http-sa
spec:
  targetRef:
    group: policy.linkerd.io
    kind: Server
    name: admin
  requiredAuthenticationRefs:
    - name: prometheus
      kind: MeshTLSAuthentication
      group: policy.linkerd.io
```

Invoking `linkerd authz` would return nothing, but after this change we
can see the auth:

```
$ linkerd authz -n emojivoto deploy/web
ROUTE   SERVER  AUTHORIZATION_POLICY   SERVER_AUTHORIZATION
*       admin   web-http-sa
```

Signed-off-by: Ivan Porta <[email protected]>

…ck --proxy` (linkerd#14779)

(Extracted from linkerd#14566)

The "opaque ports are properly annotated" check had a bug where it only
validated regular containers, missing ports in init containers (native
sidecars). This meant mismatched annotations between pods and services
could go undetected when the port belonged to an init container.

When a service had the opaque-ports annotation but the corresponding pod
did not, the check would incorrectly pass if the port was defined in an
init container instead of a regular container.

This commit extends the check to validate ports in both regular containers
and init containers, ensuring consistent opaque-ports annotations across
pods and services regardless of where the port is defined.

Signed-off-by: Ivan Porta <[email protected]>

…4767)

(Extracted from linkerd#14566)

This improves the injector logic by accounting for ports exposed in native sidecar containers:

- when consuming the `config.linkerd.io/opaque-ports` annotations
  pointing to (named or integer) ports in init containers
- when populating the proxy's `LINKERD2_PROXY_INBOUND_PORTS` env var

The `webhook_tests.go` have been expanded to test injection to a pod
with a memcached native sidecar container (never mind the contrivedness
of the example).

Signed-off-by: Ivan Porta <[email protected]>

…kerd#14786)

Those types of ports were getting ignored in `getProfile` responses. A
new test case was added that clarifies an example, that wouldn't pass
before this fix.

(Extracted from linkerd#14566)

Signed-off-by: Ivan Porta <[email protected]>

…etProfile (linkerd#14791)

(Extracted from linkerd#14566)

When hitting pods directly at their their IPs, ports in native sidecars
that were marked as opaque via the `config.linkerd.io/opaque-ports`
annotation, weren't really being marked as opaque.

More concretely, the issue layed in the getProfile API, that was
forgoing init containers when iterating over containers in this
particular case.

Endpoint profile translator tests got expanded, testing for opaque ports
in both init and regular containers.

Signed-off-by: Ivan Porta <[email protected]>

(Extracted from #14566)

The `Get` API wasn't surfacing ports marked as opaque in Servers, when:

1. ports belonged to a native sidecar (inside an init container)
2. port was referred to by name

Also changed a test fixture to use port name instead of number in order
to test this issue.