Feature summary (what you would like to be able to do and where):

Currently if a port is exposed from a job, then the service/container is accessible to all tools (via <name>.tool-<tool name>.svc.tools.local).

While this can be useful to allow cross tool usage, when running 'backend' services scoped to a specific tool it potentially opens up unexpected usage.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):

ClueBot NG runs a number of services, which the primary process uses, 2 examples of this are core (the scoring engine) and irc-relay (UDP -> Libera).

Both of these services are only intended to be consumed by bot, which is the production instance of ClueBot NG.

Applying a network policy to the namespace along the lines of

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-core
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: core
  ingress:
  - from:
    # Bot uses Core for scoring
    - podSelector:
        matchLabels:
          app.kubernetes.io/name: bot

Does appear to limit access, however this is once again going outside of the "supported" usage of toolforge.

Note: I do also use cross tool access, for example cluebotng-review using the IRC Relay; this could however be replaced with a local instance if a only allow from same namespace or everywhere policy was desired.

Benefits (why should this be implemented?):

• Security; outside of webservice type tools I was not expecting services to be exposed 'publicly'
• Limit complexity; having to implement authentication mechanisms in (especially existing) backend services would introduce more overhead for maintainers and bring in management of secrets
• This is a well supported pattern in k8s, only the wrapper tooling needs to add support (as it does for Service/Deployment objects)