Uploaded image for project: 'OpenShift Pipelines'
  1. OpenShift Pipelines
  2. SRVKP-2911

GH token scope to be extended to multiple repos in PAC

    XMLWordPrintable

Details

    • 5
    • False
    • None
    • False
    • Hide
      By default, the Github token that Pipelines as Code generates is scoped only to the repository where the payload comes from.
      However, in some cases, the developer team might want the token to allow control over additional repositories.

      scope of the Github token extended in two ways

      1. Global configuration: extend the Github token to a list of repositories in different namespaces and admin have access to set this configuration.

      2. Repository level configuration: extend the Github token to a list of repositories that exist in the same namespace as the original repository
      and both admin, non-admin have access to set this configuration.

      ## Note:
      Ignore Scoping of Github token for webhook based usecases.

      ## Prerequisite

      In the `pipelines-as-code` configmap, set the `secret-github-app-token-scoped` key to `false`.
      This setting enables the scoping of the Github token to private and public repositories listed under the Global and Repository level configuration.

      ## Scoping the Github token using Global configuration

      You can use the global configuration to use as a list of repositories used from any Repository CR in any namespaces.

      To set the global configuration, in the `pipelines-as-code` configmap, set the `secret-github-app-scope-extra-repos` key, as in the following example:

        ```yaml
        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: pipelines-as-code
          namespace: pipelines-as-code
        data:
          secret-github-app-scope-extra-repos: "owner2/project2, owner3/project3"
        ```

      ## Scoping the Github token using Repository level configuration

      You can use the `Repository` custom resource to scope the generated Github token to a list of repositories.
      The repositories can be public or private, but must reside in the same namespace as the repository with which the `Repository` resource is associated.

      Set the `github_app_token_scope_repos` spec configuration within the `Repository` custom resource, as in the following example:

        ```yaml
        apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
        kind: Repository
        metadata:
          name: test
          namespace: test-repo
        spec:
          url: "https://github.com/linda/project"
          settings:
            github_app_token_scope_repos:
            - "owner/project"
            - "owner1/project1"
        ```

      In this example, the `Repository` custom resource is associated with the `linda/project` repository in the `test-repo` namespace.
      The scope of the generated Github token is extended to the `owner/project` and `owner1/project1` repositories, as well as the `linda/project` repository. These repositories must exist under the `test-repo` namespace.

      **Note:**

      If any of the repositories does not exist in the namespace, the scoping of the Github token fails with an error message as in the following example:

      ```console
      failed to scope Github token as repo owner1/project1 does not exist in namespace test-repo
      ```
      Show
      By default, the Github token that Pipelines as Code generates is scoped only to the repository where the payload comes from. However, in some cases, the developer team might want the token to allow control over additional repositories. scope of the Github token extended in two ways 1. Global configuration: extend the Github token to a list of repositories in different namespaces and admin have access to set this configuration. 2. Repository level configuration: extend the Github token to a list of repositories that exist in the same namespace as the original repository and both admin, non-admin have access to set this configuration. ## Note: Ignore Scoping of Github token for webhook based usecases. ## Prerequisite In the `pipelines-as-code` configmap, set the `secret-github-app-token-scoped` key to `false`. This setting enables the scoping of the Github token to private and public repositories listed under the Global and Repository level configuration. ## Scoping the Github token using Global configuration You can use the global configuration to use as a list of repositories used from any Repository CR in any namespaces. To set the global configuration, in the `pipelines-as-code` configmap, set the `secret-github-app-scope-extra-repos` key, as in the following example:   ```yaml   apiVersion: v1   kind: ConfigMap   metadata:     name: pipelines-as-code     namespace: pipelines-as-code   data:     secret-github-app-scope-extra-repos: "owner2/project2, owner3/project3"   ``` ## Scoping the Github token using Repository level configuration You can use the `Repository` custom resource to scope the generated Github token to a list of repositories. The repositories can be public or private, but must reside in the same namespace as the repository with which the `Repository` resource is associated. Set the `github_app_token_scope_repos` spec configuration within the `Repository` custom resource, as in the following example:   ```yaml   apiVersion: "pipelinesascode.tekton.dev/v1alpha1"   kind: Repository   metadata:     name: test     namespace: test-repo   spec:     url: " https://github.com/linda/project "     settings:       github_app_token_scope_repos:       - "owner/project"       - "owner1/project1"   ``` In this example, the `Repository` custom resource is associated with the `linda/project` repository in the `test-repo` namespace. The scope of the generated Github token is extended to the `owner/project` and `owner1/project1` repositories, as well as the `linda/project` repository. These repositories must exist under the `test-repo` namespace. **Note:** If any of the repositories does not exist in the namespace, the scoping of the Github token fails with an error message as in the following example: ```console failed to scope Github token as repo owner1/project1 does not exist in namespace test-repo ```
    • 5
    • Pipelines Sprint 236, Pipelines Sprint 237, Pipelines Sprint 238, Pipelines Sprint 239

    Description

      Their is a use case where CI Repos Differ from CD Repos, and the teams would like the generated GH Token from PAC to allow control over these secondary repos, even if they were not the one triggering the pipeline.

      1. Both Repos would be assigned to the same Kuberentes Namespace.
      2. Some sort of method for allowing the added scope to the repos.

      What is the business impact? Please also provide timeframe information.
      N/A

      Attachments

        Issue Links

          Activity

            People

              sashture Savita .
              rh-ee-ksaha Koustav Saha
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: