NetworkPolicy

The operator can manage NetworkPolicy resources for Tekton component workloads. TektonPipeline (core controllers, resolvers, and proxy-webhook), TektonTrigger, TektonChain, Pipelines-as-Code, ManualApprovalGate, TektonPruner, TektonResult, and MultiCluster components (TektonScheduler, TektonMulticlusterProxyAAE, SyncerService) are supported; other components will be added later.

Configuration is available via TektonConfig:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  networkPolicy:
    disabled: false          # set to true to remove all managed NetworkPolicies
    policies:                # override or add policies by name
      triggers-controller:   # replaces the default triggers-controller policy
        podSelector:
          matchLabels:
            app: tekton-triggers-controller
        policyTypes: [Ingress]
        ingress:
          - ports:
              - port: 9000

The networkPolicy field is propagated from TektonConfig to TektonPipeline, TektonTrigger, TektonChain, TektonPruner, TektonResult, Pipelines-as-Code, and MultiCluster components. When those component CRs are managed by TektonConfig (the usual install path), TektonConfig is the source of truth: edits to spec.networkPolicy on the component CRs alone are overwritten on the next Config reconcile. Configure NetworkPolicy via TektonConfig.spec.networkPolicy.

Default Policies

When NetworkPolicy is enabled (the default), the following policies are applied to the operand namespace (e.g. tekton-pipelines or openshift-pipelines):

TektonPipeline

TektonTrigger

TektonChain

OpenShift Pipelines-as-Code

ManualApprovalGate

The networkPolicy field is available directly on the ManualApprovalGate CR (MAG is a standalone CR, not managed through TektonConfig):

apiVersion: operator.tekton.dev/v1alpha1
kind: ManualApprovalGate
metadata:
  name: manual-approval-gate
spec:
  networkPolicy:
    disabled: false

TektonPruner

TektonResult

API and retention DB egress is port-only (no pod/CIDR peer). NetworkPolicy cannot match on hostname or JDBC URL, so restricting To to in-cluster postgres pods would break external databases. Configure db_host / db_port as usual; when db_port changes in the Results Spec, the operator regenerates these policies on reconcile. No custom NetworkPolicy is required for an external database.

Administrative / debug access to in-cluster Postgres

results-postgres ingress allows only Results API and retention-policy-agent pods. One-off workloads (DB migrations, psql debug pods) are otherwise dropped once NetworkPolicy is enabled.

Recommended: add a dedicated temporary NetworkPolicy that allows a dedicated admin label. Do not reuse app: tekton-results-api on a debug pod — that label is also used by the Results API Service selector and can route API traffic to the wrong pod. A dedicated label (below) avoids that.

Apply directly:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: results-postgres-admin
  namespace: tekton-pipelines   # or openshift-pipelines
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: tekton-results-postgres
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: tekton-results-db-admin
      ports:
        - protocol: TCP
          port: 5432   # match Spec db_port when customized

Or the same rule via spec.networkPolicy.policies (use a new name so you do not replace a managed default):

spec:
  networkPolicy:
    policies:
      results-postgres-admin:
        podSelector:
          matchLabels:
            app.kubernetes.io/name: tekton-results-postgres
        policyTypes: [Ingress]
        ingress:
          - from:
              - podSelector:
                  matchLabels:
                    app: tekton-results-db-admin
            ports:
              - protocol: TCP
                port: 5432

Label the migration/psql pod with app: tekton-results-db-admin, then remove the policy (or the policies entry) when finished.

Emergency only: temporarily set spec.networkPolicy.disabled: true (on TektonConfig when Config manages Results), run the admin work, then set disabled: false again. Prefer the dedicated admin NetworkPolicy above so other workloads stay locked down.

Console Plugin (OpenShift only)

The console plugin is a static file server (nginx) — all API calls run in the user’s browser via the OpenShift Console’s proxy, not on this pod.

These are static manifests shipped with the TektonConfig console plugin resources, not reconciled via spec.networkPolicy.

TektonScheduler

Policies are applied to the operand namespace (tekton-pipelines or openshift-pipelines).

TektonMulticlusterProxyAAE

Policies are applied to the operand namespace (tekton-pipelines or openshift-pipelines). Deployed only when the scheduler is enabled with multi-cluster role = Hub.

SyncerService (OpenShift only)

Policies are applied to the operand namespace (openshift-pipelines). Deployed only when the scheduler is enabled with multi-cluster role = Hub.

All component policies (TektonPipeline, TektonTrigger, TektonScheduler, TektonMulticlusterProxyAAE, SyncerService, and Console Plugin) are applied to the operand namespace (e.g. tekton-pipelines or openshift-pipelines).

Platform differences

Disabling

spec:
  networkPolicy:
    disabled: true

This removes all managed NetworkPolicies from the operand namespace.

Overriding a policy

Entries in spec.networkPolicy.policies replace or add policies by name. To override a default policy, use the same name (e.g. triggers-controller). New names add additional policies alongside the defaults.