## Overview This issue was generated with GitLab Duo and outlines the implementation plan for adding ID Tokens and Secrets support to Flows execution. ## Problem Statement Currently, Flows only pass a limited subset of variables into their execution environment. While Flows run under runners (similar to CI/CD jobs), they don't use CI/CD YAML directly and therefore don't have access to ID tokens or secrets management features that are available in standard CI/CD jobs. ## Implementation Strategy To add ID Tokens and Secrets support to Flows, we need to extend the `StartWorkflowService` to generate ID tokens similar to how CI/CD jobs do it. The infrastructure already exists in `Ci::Build` and can be adapted for workload contexts. ### Step 1: Add ID Tokens to Flow Definition Extend the flow YAML schema to support `id_tokens` similar to CI/CD jobs. This would be defined in the flow's `agent-config.yml`: ```yaml id_tokens: VAULT_ID_TOKEN: aud: https://vault.example.com AWS_ID_TOKEN: aud: https://aws.example.com ``` ### Step 2: Generate ID Tokens in StartWorkflowService Add a method to generate ID tokens for the workload in `ee/app/services/ai/duo_workflows/start_workflow_service.rb`: ```ruby def id_tokens_variables Gitlab::Ci::Variables::Collection.new.tap do |variables| id_tokens = @params[:id_tokens] || {} break variables if id_tokens.empty? sub_components = project.ci_id_token_sub_claim_components.map(&:to_sym) id_tokens.each do |var_name, token_data| token = Gitlab::Ci::JwtV2.for_workload( workload_user: @workload_user, project: project, aud: expanded_id_token_aud(token_data['aud']), sub_components: sub_components ) variables.append(key: var_name, value: token, public: false, masked: true) end rescue OpenSSL::PKey::RSAError, Gitlab::Ci::Jwt::NoSigningKeyError => e Gitlab::ErrorTracking.track_exception(e) end end ``` ### Step 3: Integrate into Variables Method Merge ID token variables into the main `variables` method: ```ruby def variables base_variables = git_clone_variables.merge( # ... existing variables ... ) base_variables.merge(sandbox.environment_variables) .merge(id_tokens_variables) # Add this line end ``` ### Step 4: Create JWT Generation for Workloads You may need to create a `Gitlab::Ci::JwtV2.for_workload` method or adapt the existing `for_build` method to work with workload contexts instead of build objects. Key considerations: - ID tokens are currently tied to `Ci::Build` objects - Abstract the JWT generation to work with workload contexts - Flows already use composite identity for the workload user, which is compatible with ID token generation ### Step 5: Handle Secrets For secrets (like Vault integration), follow the same pattern as CI/CD by: - Accepting `secrets` configuration in flow params - Using the generated ID tokens to authenticate with secret providers - Injecting resolved secrets as environment variables Reference: `doc/ci/secrets/hashicorp_vault.md` and `doc/ci/secrets/id_token_authentication.md` ### Step 6: Update Documentation Add the new variables to `doc/user/duo_agent_platform/flows/execution_variables.md` listing available ID tokens and secrets. ## Key Implementation Details **Current Flow Variable Generation** (`ee/app/services/ai/duo_workflows/start_workflow_service.rb`): - The `variables` method builds a hash of environment variables passed to the workload - Currently includes git-related variables and DUO_WORKFLOW-specific variables - Does not include ID tokens or secrets **ID Token Generation Pattern** (from `app/models/ci/build.rb`): - CI/CD jobs generate ID tokens through the `id_tokens_variables` method - Uses `Gitlab::Ci::JwtV2.for_build` to create JWT tokens - Tokens are marked as `masked: true` to prevent exposure in logs - Supports variable expansion in the `aud` claim **Composite Identity Compatibility**: - Flows already use composite identity for the workload user - This is compatible with ID token generation - The workload user can be either a service account or the current user ## Acceptance Criteria - [ ] ID tokens can be defined in flow configuration - [ ] ID tokens are generated and passed as environment variables to flow execution - [ ] ID tokens are properly masked in logs - [ ] Secrets can be resolved using ID tokens (Vault integration) - [ ] Documentation is updated with available ID token and secrets variables - [ ] Tests cover ID token generation and variable masking - [ ] Backward compatibility is maintained (only pass ID tokens if explicitly configured) ## Related Issues/Documentation - [ID token authentication](https://docs.gitlab.com/ee/ci/secrets/id_token_authentication.html) - [HashiCorp Vault secrets](https://docs.gitlab.com/ee/ci/secrets/hashicorp_vault.html) - [Flow execution variables](https://docs.gitlab.com/ee/user/duo_agent_platform/flows/execution_variables.html) - [Flow execution configuration](https://docs.gitlab.com/ee/user/duo_agent_platform/flows/execution.html)