securitycurlgithub-apigithub-actionsazure-acr

GitHub Action Repository Secrets & how to secure client_payload repo dispatch event Azure Container Registry


Is there a way to pass data securely from between repos using the client_payload in a repository dispatch event?

I create a repository dispatch event for a CI pipeline I have between my two of my repos. My first repo uses Terraform in a GitHub Action to create Azure cloud resources and then is suppose to take the outputs for the sever address, username, and password of my container registry resource created using my azure.tf script.

In the final step of my GitHub Action in the first repo, it makes a POST request curl to notify my second repo that the initial cloud resources for the Azure Container Registry (ACR) have been created. It should now be safe to build my container images from my second repo and push them to ACR.

My problem is with the client_payload being sent over to my second repo, it is using unsecure raw json that will expose the password most importantly and other information in the output string of my running CI jobs under the GitHub action in my second repo.

This is why I'd like to understand if there's a way to pass data securely from between repos using the client_payload?

curl --location --request POST 'https://api.github.com/repos/ME_SECOND_REPO_WITH_THE_CONTAINERS/dispatches' \
--header 'Accept: application/vnd.github.everest-preview+json' \
--header 'Authorization: token <MY_PAT>' \
--header 'Content-Type: application/json' \
--data-raw '{
  "event_type": "MY_EVENT_TYPE",
  "client_payload": {
    "login_server": "UNSECURE_VALUE",
    "username": "UNSECURE_VALUE",
    "password": "UNSECURE_VALUE"
  }
}'

Solution

  • Organization Secrets

    Github Action recently launched something called organization secrets. That would be a better way to handle the service account credentials (assuming you are using service accounts).

    Manually trigger workflow

    If you don't have service account setup, then the most recent workflow_dispatch offering might be a better fit.

    Workflow

    on: 
      workflow_dispatch:
        inputs:
          logLevel:
            description: 'Log level'     
            required: true
            default: 'warning'
          tags:
            description: 'Test scenario tags'  
    

    Trigger screenshot: screenshot

    Modified workflow would be like

    on: 
      workflow_dispatch:
        inputs:
          login_server:
            description: 'login server'     
            required: true
            default: "xx.xx.xx.xx"
          username:
            description: 'username'  
            required: true
          password:
            description: 'password'  
            required: true        
    

    And you can use access them as

    EDIT: To enable some level of Obfuscating

    Masking a value in log