---
# System prepended metadata

title: Pipelines-as-Code and Security

---

With [Pipelines-as-Code](https://pipelinesascode.com), you can effortlessly connect your code on popular Git platforms like GitHub to your Tekton Pipelines.

One of the key benefits of Pipelines-as-Code is its contribution to security. It empowers you to ensure that only trusted contributors or owners have the ability to run your Pipelines.

## Default execution rules

By default, when a user sends a Pull Request to your repository, the PipelineRun will only be executed if:

- The user is an Owner or a Collaborator of the repository.
- The user is a member of the organization and the repository is owned by the organization.

If the user does not match any of the above conditions, the PipelineRun will not run.

## Gitops comment for allowing external user

An Owner or a Collaborator can also add a comment to the Pull Request to trigger the PipelineRun by adding the GitOps comment `/ok-to-test` to the Pull Request. Any subsequent iterations on the Pull Request with a new commit (or a commit amend) will require the `/ok-to-test` comment to be added again.

We enforce the requirement of adding this comment to the Pull Request so that any malicious changes need to be properly vetted for by external users.

## Allowing user with an OWNERS file

If we trust the user and want to allow them to run the PipelineRun automatically without adding them as a Contributor to the repository, we can add them to an `OWNERS` file at the root of the repository. This file follows a format similar to the prow `OWNERS` file. An example would be:

```yaml
approvers:
    - user1
```

The `OWNERS` file definition is read from the default branch directly from the repository to avoid any malicious injection in a Pull Request.

Using a OWNERS file instead of having to add it as a collaborator let the administrator only let those users to run Pipelines-as-Code CI instead of being a full collaborator on Repository and respect better the Piplines-as-Code philosophy where all your CI configuration is used in your code.

## PipelineRun definition source

By default, the PipelineRun definition is read from the commit tree where the Pull Request is created. This makes it easy to test the PipelineRun definition directly via the Pull Request with your code change.

For example, when you add a Python script to your GO repository, you can include your script and a change to your PipelineRun to add a linter or test task like `pylint/pytest`, and this will automatically run on your Pull Request.

In some cases where security is a concern, you may want to run the PipelineRun definition from the default branch of the repository. This can be done by adding the provenance field in the settings of the Repository CR:

```yaml
apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: my-repo
spec:
  url: "https://github.com/owner/repo"
  settings:
    pipelinerun_provenance: "default_branch"
```

This makes it harder for a malicious user to inject changes into the PipelineRun definition.

## GitHub token generation

When the PipelineRun is triggered from a Pull Request, we generate a temporary GitHub token available for 8 hours. This temporary token helps users checking out private repositories with the `git-clone` task.

The generated token is only available to the repository from where the event originated.

There are multiple settings globally or on repo CR to allow you to customize the scope of this token. One useful feature is the ability to automatically scope the token to other Repositories that have a repository CR in the same namespace. This allows you to perform operations on different repos via the GitHub API easily without granting your token access to every repository in the organization.

The token generation is a feature that can be disabled globally or per repository.

## Pipelines as Code Policy

Starting from OpenShift Pipelines 1.12.0, we have introduced the concept of Policy on Pipelines as Code.

 This allows you to specify which GitHub team members of a team can trigger certain actions.

Currently, this feature is only supported with the GitHub and Gitea Providers.

The actions that can be specified are `ok_to_test` and `pull_request`. For example, we set up a group of users from the GitHub team `team-ok-to-test` to be allowed to run the `/ok-to-test` command for external users. Similarly, a group of users from the GitHub team `team-pull-request` is allowed to have their Pull Requests automatically run.

## Future improvements

We are actively working on several improvements to make Pipelines-as-Code even more secure:

- Integration with [Enterprise Contract](https://enterprisecontract.dev/), making it easy to verify the provenance and artifacts of tasks on every pull request validated by Pipelines-as-Code. You can follow the progress of this improvement in the Jira issue [SRVKP-3084](https://issues.redhat.com/browse/SRVKP-3084).
- Allowing PipelineRuns to run only on certain commits that are signed by specific users. This allows you to completely avoid running CI on PRs that are not authorized for certain users unless they are signed with a valid GPG/ED25519 key. You can follow the progress of this improvement in the Jira issue [SRVKP-3085](https://issues.redhat.com/browse/SRVKP-3085).
