How do you implement RBAC and security policies for Tekton in a multi-team environment?

Securing Tekton in a multi-team environment requires thinking beyond simple access control lists to a comprehensive security architecture that addresses four distinct threat surfaces: who can define pipelines, what those pipelines can do at runtime, how pipeline credentials are scoped, and what governance policies ensure pipeline definitions comply with organizational standards. A developer on the payments-api team should be able to create and run pipelines in their namespace but must not be able to read secrets from the user-auth-service namespace, modify shared ClusterTasks used by all teams, or run pipeline steps with privileged container access that could compromise the node.

Kubernetes RBAC forms the foundation layer. Custom Roles define the specific Tekton API operations each team can perform. A pipeline-developer Role grants create, get, list, and watch permissions on Pipelines, Tasks, PipelineRuns, and TaskRuns within the team's namespace, along with read access to ClusterTasks and ClusterPipelines that provide shared reusable components. A pipeline-admin Role additionally grants update and delete permissions plus the ability to manage EventListeners and TriggerBindings for webhook integrations. A pipeline-viewer Role provides read-only access for stakeholders who need to monitor pipeline status without modification rights. These Roles are bound to team groups through RoleBindings, with the group membership managed by the organization's identity provider through OIDC integration with the Kubernetes API server.

ServiceAccount isolation is the critical runtime security boundary. Each team's PipelineRuns execute under a team-specific ServiceAccount rather than a shared or default service account. The checkout-service team's ServiceAccount has an ImagePullSecret for their team's registry namespace, a Secret containing their deployment credentials for the staging environment, and RBAC permissions scoped to their namespace. When a PipelineRun executes, the TaskRun pods inherit the ServiceAccount's identity, and any Kubernetes API calls from within the pipeline steps are authorized against that ServiceAccount's RBAC bindings. This prevents a malicious or misconfigured pipeline step from accessing resources outside the team's boundary. Critical secret isolation ensures that the payments-api team's database credentials are stored in their namespace and accessible only to their ServiceAccount, while the order-processing-service team cannot reference those secrets even if they know the secret name.

Policy engines like OPA Gatekeeper or Kyverno provide governance over pipeline definitions that RBAC alone cannot enforce. While RBAC controls who can create a Pipeline resource, policy engines control what that Pipeline can contain. Policies can enforce that all TaskRun steps must use images from an approved internal registry rather than arbitrary public images, that no pipeline step can run as root or with privileged security context, that all PipelineRuns must include a security scanning task before the image build task, that resource requests and limits must be specified for every step to prevent resource exhaustion, and that all pipeline workspaces must use volumeClaimTemplates rather than hostPath volumes. These policies are evaluated at admission time when the Pipeline or PipelineRun resource is created, rejecting non-compliant definitions with a descriptive error message before they ever execute.

Audit logging and monitoring complete the security architecture. Kubernetes audit logs capture every Tekton API operation with the authenticated identity, providing a compliance-ready trail of who created, modified, or triggered each pipeline. Prometheus metrics from the Tekton controller track pipeline execution patterns, and alerting rules flag anomalies such as pipeline runs executing at unusual hours, pipelines accessing resources outside their normal scope patterns, or sudden increases in failed pipeline runs that might indicate credential compromise. For the inventory-sync service pipeline, audit policies can be configured to log every access to production deployment credentials at the RequestResponse level, creating a complete record of when production deployments were triggered and by whom. Integration with SIEM platforms like Splunk or Elastic Security enables correlation of Tekton activity with broader infrastructure security events, detecting scenarios where a compromised developer account attempts to modify pipeline definitions to exfiltrate secrets through build step output logs.