Secure Sonarqube instance with Cloudflare Access

SonarQube Server / Community Build
,
8

We had the same problem and we approached it and solved it using the following steps.

  1. Configure WARP to access Cloudflare protected instance:
    We created a COMPOSITE Github actions that runs directly in the GH actions specific worker machine (not inside docker) as follows:
name: 'Configure Cloudflare WARP'
description: 'Configure Cloudflare WARP for accessing protected CF instances'
runs:
  using: "composite"
  steps:
    - run: echo "${{ github.action_path }}" >> $GITHUB_PATH
      shell: bash
    - name: install warp-cli
      shell: bash
      run: |
        curl https://pkg.cloudflareclient.com/pubkey.gpg | sudo gpg --yes --dearmor --output /usr/share/keyrings/cloudflare-warp-archive-keyring.gpg
        echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/cloudflare-warp-archive-keyring.gpg] https://pkg.cloudflareclient.com/ focal main' | sudo tee /etc/apt/sources.list.d/cloudflare-client.list
        sudo apt update
        sudo apt install cloudflare-warp -y
    - name: create mdm.xml file
      shell: bash
      run: |
        cat > mdm.xml <<EOF
        <dict>
          <key>organization</key>
          <string>your_organization</string>
          <key>auth_client_id</key>
          <string>${CLOUDFLARE_ACCESS_CLIENT_ID}</string>
          <key>auth_client_secret</key>
          <string>${CLOUDFLARE_ACCESS_CLIENT_SECRET}</string>
        </dict>
        EOF
        sudo mv mdm.xml /var/lib/cloudflare-warp/
    - name: init connection
      shell: bash
      run: warp-cli --accept-tos connect
    - name: wait for connection
      shell: bash
      run: |
        echo "Waiting for connection..."
        until warp-cli --accept-tos account | grep -q "Team"; do
          sleep 1
        done
        echo "Warp is now connected!"
  1. Create a COMPOSITE action that downloads SonarQube scanner cli and performs the analysis as following
name: 'SonarQube Analysis action'
description: 'Install sonar-scanner and perform analysis'
inputs:
  propertyFile:
    description: 'Path to sonar-project.properties file'
    required: false
    default: 'sonar-project.properties'
  projectVersion:
    description: 'Project version'
    required: false
    default: 'test_version'
runs:
  using: "composite"
  steps:
    - name: Install SonarQube
      shell: bash
      run: |
        wget https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-5.0.1.3006-linux.zip
        unzip sonar-scanner-cli-5.0.1.3006-linux.zip
        sudo mv sonar-scanner-5.0.1.3006-linux /opt/
        ln -s /opt/sonar-scanner-5.0.1.3006-linux/bin/sonar-scanner /usr/local/bin/sonar-scanner
    - name: Run SonarQube analysis
      shell: bash
      run: |
        sonar-scanner -Dproject.settings=${{ inputs.propertyFile }} -Dsonar.host.url=${SONARQUBE_URL} -Dsonar.login=${SONARQUBE_API_TOKEN} -Dsonar.projectVersion=${{ inputs.projectVersion }}

Therefore by using sequentially those 2 actions we bypassed the problem.

      - name: Configure Cloudflare WARP
        uses: action1
        env:
          CLOUDFLARE_ACCESS_CLIENT_ID: *******
          CLOUDFLARE_ACCESS_CLIENT_SECRET: ******
      - name: SonarQube analysis
        uses: action2
        env:
          SONARQUBE_URL: ******
          SONARQUBE_API_TOKEN:******
        with:
          projectVersion: test

We didn’t use one of the existing marketplace actions that run SonarQube because those were running inside a container in which case the first step had no effect when running inside container. That’s why the 2 custom GH actions were composite eunning directly in tha bash shell of the coresponding runner

More on custom GH actions and the types of them here

2 Likes