fix(kubernetes-client): resolve named service target ports

[GrosQuildu]

Fabric8's Service port-forward implementation resolves numeric Service targetPort values, but it does not resolve named targetPort values.

For a Service port with targetPort: "http", ServiceOperationsImpl calls getTargetPort().getIntVal(). That returns null, so Fabric8 falls back to the Service port and forwards to the wrong Pod port.

This affects the Service port-forward overloads that delegate through ServiceOperationsImpl:

• portForward(int, ReadableByteChannel, WritableByteChannel)
• portForward(int)
• portForward(int, int)
• portForward(int, InetAddress, int)

Expected Behavior And kubectl Parity

Kubernetes Services support targetPort as either a number or a name. A named targetPort is resolved against the selected Pod's named container ports.

kubectl port-forward service/... performs this Service-port-to-Pod-port translation before opening the Pod portforward stream. Fabric8's Service port-forward API should do the same. If the name cannot be resolved on the selected Pod, it should fail closed instead of silently falling back to the Service port.

Deduplication found upstream issue fabric8io/kubernetes-client#7372 and PR #7394, but that fix only handled numeric targetPort values. The named targetPort case remains unresolved.

Exploit Scenario And PoC

A platform exposes a restricted "connect to my service" workflow backed by Fabric8. Users can choose a namespace, Service name, and Service port, but they cannot choose an arbitrary Pod or Pod port. The platform's Kubernetes credentials can read Services, list matching Pods, and create Pod port-forward streams.

The target Service exposes public HTTP on Service port 80 and maps it to a named Pod port:

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
  - port: 80
    targetPort: http

The selected Pod has the public HTTP listener on named container port http at Pod port 8080, but also has a pod-local admin listener on numeric port 80:

containers:
- name: web
  ports:
  - name: admin
    containerPort: 80
  - name: http
    containerPort: 8080

The platform calls the Service-level API:

PortForward pf = client.services()
    .inNamespace("test")
    .withName("web")
    .portForward(80, inChannel, outChannel);

Expected result: Fabric8 resolves targetPort: "http" to Pod port 8080 and opens:

.../pods/<pod>/portforward?ports=8080

Actual result: Fabric8 ignores the string target port, falls back to the Service port, and opens:

.../pods/<pod>/portforward?ports=80

The user receives a tunnel to the pod-local admin listener even though the exposed workflow only allowed Service-level access to port 80.

Threat Model

This is in scope when a downstream application exposes Fabric8 Service port-forwarding to lower-privileged users through higher-privileged Kubernetes credentials.

The attacker only needs access to that Service-level workflow and control over, or access to, a Service that uses a named targetPort. The attacker does not need direct Pod exec or arbitrary Pod port-forward permission.

Suggested Fix

Resolve string targetPort values against the selected Pod's named container ports before delegating to Pod port-forwarding.

The resolver should:

• keep existing numeric targetPort behavior;
• resolve targetPort.getStrVal() by matching Pod container port names;
• match protocol defaults consistently with Kubernetes;
• fail closed when the named target port is absent;
• preserve kubectl-compatible behavior for headless Services.

Validation

A regression test should assert that a Service with port: 80 and targetPort: "http" forwards to the selected Pod's named container port 8080, not Pod port 80.

On the vulnerable implementation:

Expected: portforward?ports=8080
Actual:   portforward?ports=80

With the patch applied:

./mvnw -B -ntp -pl kubernetes-client -Dtest=ServiceOperationsImplTest test

Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS

---

Paweł Płatek from Trail of Bits in collaboration with OpenAI.