Skip to main content
Version: Next

Workflow Workload Configuration

CI workflows in OpenChoreo use the generate-workload ClusterWorkflowTemplate to create and update Workload CRs via the OpenChoreo API. This workflow step authenticates as a service account using the OAuth 2.0 client credentials grant.

By default, OpenChoreo ships with Thunder as the identity provider and a pre-configured OAuth client (openchoreo-workload-publisher-client) for development and testing. When using an external identity provider, platform engineers must configure the OAuth application, store the credentials, update the workflow template, and set up the authorization binding.

Prerequisites​

Before configuring, ensure you have:

  1. An external identity provider integrated with OpenChoreo (see Identity Provider Configuration)
  2. Access to create OAuth applications in your identity provider
  3. kubectl access to the cluster

Step 1: Create an OAuth Application​

Create an OAuth 2.0 application in your identity provider with the following settings:

  • Grant Type: client_credentials (service-to-service authentication)
  • Token Format: JWT (not opaque tokens)

Note the client ID and client secret — you will need them in the following steps.

Step 2: Store the Client Secret​

Store the OAuth client secret in a Kubernetes secret so it can be mounted into workflow steps:

kubectl create secret generic workload-publisher-oauth-secret \
  -n <workflow-plane-namespace> \
  --from-literal=client-secret="<YOUR_OAUTH_CLIENT_SECRET>"
tip

For managing secrets in production environments, refer to the Secret Management guide for best practices using External Secrets Operator.

Step 3: Update the ClusterWorkflowTemplate​

The generate-workload ClusterWorkflowTemplate accepts OAuth and API server parameters as inputs. Update the default values to point to your identity provider and API server:

- name: generate-workload-cr
  inputs:
    parameters:
      - name: oauth-token-url
        default: "https://your-idp.example.com/oauth2/token"
      - name: oauth-client-id
        default: "<your-client-id>"
      - name: oauth-client-secret
        default: "<your-client-secret>"
      - name: api-server-url
        default: "<your-api-server-url>"
ParameterDescription
oauth-token-urlYour identity provider's token endpoint
oauth-client-idClient ID of the OAuth application created in Step 1
oauth-client-secretClient secret (or reference to Kubernetes secret)
api-server-urlURL of the OpenChoreo API server
tip

For production deployments, mount the client secret from the Kubernetes secret into the workflow step as an environment variable or volume, rather than passing it as a workflow parameter. Refer to the Argo Workflows documentation for details on referencing secrets in workflow templates.

See the sample workflow template for a complete example.

Step 4: Configure Authorization​

The workload publisher authenticates as a service account using the client_credentials grant. The OpenChoreo API matches the sub claim in the JWT to identify the caller. You must grant the new client the workload-publisher role via a bootstrap authorization mapping.

OpenChoreo ships with a default workload-publisher role that has the minimum required permissions:

- name: workload-publisher
  system: true
  actions:
    - "workload:create"
    - "workload:update"
    - "workflowrun:view"
    - "workflowrun:update"

Add the following to your Control Plane Helm values, replacing <your-client-id> with the client ID from Step 1:

openchoreoApi:
  config:
    security:
      authorization:
        bootstrap:
          mappings:
            - name: workload-publisher-binding
              kind: ClusterAuthzRoleBinding
              system: true
              roleMappings:
                - roleRef:
                    name: workload-publisher
                    kind: ClusterAuthzRole
              entitlement:
                claim: sub
                value: "<your-client-id>"
              effect: allow
warning

The workload-publisher role and its binding are required for CI workflows to function. When overriding the bootstrap.mappings array, make sure to include this binding along with any other bindings you want to keep. See the Authorization Configuration guide for details.

Verification​

After configuring, verify the setup:

  1. Check that the secret exists:

    kubectl get secret workload-publisher-oauth-secret -n <workflow-plane-namespace>

  2. Verify the ClusterWorkflowTemplate is updated:

    kubectl get clusterworkflowtemplate generate-workload -o yaml

  3. Verify the authorization binding was created:

    kubectl get clusterauthzrolebindings | grep workload-publisher

  4. Trigger a build and check that the workflow step successfully obtains an OAuth token and creates/updates the Workload CR.

See Also​