Request: CCI_Context Parameter

[whatisdot]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

Currently, there is no way for us to specify the CircleCI Context when triggering a pipeline with this Action. It's possible to set a string representing the name of the CircleCI Context in the GHA_Meta parameter when triggering the pipeline, but that prevents us from sending any additional data through to the workflows.

Describe the solution you'd like

An additional optional parameter named CCI_Context that, when set, will add this parameter to the POST request that triggers the CircleCI Pipeline. This is then used to set the name of the CircleCI Context.

action.yml

We would need an additional input defined:

inputs:
  # ...
  CCI_Context:
    required: false
    description: 'An optional CircleCI context to use when running jobs. Will be available on the CircleCI pipeline as CCI_Context.'

src/lib/CircleCIPipelineTrigger.ts

We adjust this to get a new input and add it to the list of parameters when it is present:

    # (constructor)
    this.cciContext = getInput("CCI_Context");

    # (triggerPipeline)
    if (this.cciContext.length > 0) {
      this.parameters.CCI_Context = this.cciContext;
    }

Teachability, documentation, adoption, migration strategy

Migration Strategy

Since the parameter is optional, teams would only need to opt-in to using it in a newer version of this Action.

Documentation

The following changes could be made to the README.

(under the "How to use" section)

3. Add the Pipeline Parameter definitions to your CircleCI config. This data will be entered by the GitHub Action when triggered.

   Add the following to the top of your .circleci/config.yml file. Ensure you are specifying version 2.1

   version: 2.1
   parameters:
     GHA_Actor:
       type: string
       default: ""
     GHA_Action:
       type: string
       default: ""
     GHA_Event:
       type: string
       default: ""
     GHA_Meta:
       type: string
       default: ""
     CCI_Context:
       type: string
       default: ""

(under the "Inputs" section)

CCI_Context

required: false

description: An optional CircleCI context to use when running jobs. Will be available on the CircleCI pipeline as CCI_Context.

jobs:
  trigger-circleci:
    runs-on: ubuntu-latest
    steps:
      - name: <customize name>
        id: <customize id>
        uses: CircleCI-Public/[email protected]
        with:
          CCI_Context: protected-context-name
        env:
          CCI_TOKEN: ${{ secrets.CCI_TOKEN }}

What is the motivation / use case for changing the behavior?

Keys/secrets in CircleCI could be exposed in certain scenarios:

1. Bad actor commits a change to expose service account keys/secrets in CircleCI when the workflow is ran.
2. Bad actor pushes commit and triggers the pipeline with their branch, exposing the secret.
3. Bad actor takes the secret and runs additional operations for bad actor purposes.
4. Operations are successful until admins are made aware and roll the token.

OpenID Connect (OIDC) solves this issue by introducing a trust relationship between two services, so that only a public key is shown when making service-to-service communication. This would address the issue, but currently CircleCI does not have an OIDC provider to accept inbound requests.

We could use CircleCI Context names in combination with GitHub Environments and GitHub branch protection rules to isolate the service account that is allowed to perform operations on specific GitHub Environments.

1. Bad actor commits a change to a GitHub Action that tries to expose a service account key/token/secret in CircleCI when it is ran.
2. Bad actor pushes commit and tries to trigger the pipeline via GitHub Action in their branch.
3. Results in failure when the GitHub Environment uses protected branches.

(or)

1. Bad actor commits a change to a GitHub Action that tries to expose a service account key/token/secret in CircleCI when it is ran.
2. Bad actor pushes commit that tries to run sensitive actions in CircleCI with the protected CircleCI Context name.
3. Results in failure because the (non protected) GitHub Environment CCI_TOKEN does not have permission to use the CircleCI Context.

[whatisdot]

@KyleTryon do you think this is a reasonable ask? I think the technical limitation also applies to CircleCI configurations that can't be configured at runtime within a pipeline/workflow, but the most immediate application I see is for improved security through CircleCI Contexts.