Make it configurable, if mode is block, to not send telemetry to API

[varunsh-coder]

When user sets this mode, e.g.

- name: Harden Runner
        uses: step-security/harden-runner@rc
        with:
          egress-policy: block
          disable-telemetry: true
          allowed-endpoints: 
            github.com:443

agent should not make calls to agent.api.stepsecurity.io.
Other allowed-endpoints can still be called.

• Do not show link - clarify that insights will not be generated
• Add this attribute to the config

[varunsh-coder]

Updated the setting to disable-telemetry instead of send-insights. It should be false by default. It should only take affect if egress-policy is block.

[varunsh-coder]

Hi @wallies, we are making good progress on this issue. Request you to please review the description to ensure it is what you were looking for. Do let us know if you have feedback on the name of the setting. As of now we are going with disable-telemetry.

Also, there are advantages to correlating the telemetry with the build log even in block mode. If an unexpected outbound call is made, it can be correlated with the exact step that made the call. In block mode, information about blocked call is anyways written to the build log. So harden-runner-app can read info from the build log (instead of from telemetry) and correlate it. So, you will be able to see what process made the unexpected call, and in what step it was made in. Do you see any concern with this approach - harden-runner-app reading info about blocked call from build log to generate insights when disable-telemetry is set to true?

[wallies]

Hi @wallies, we are making good progress on this issue. Request you to please review the description to ensure it is what you were looking for. Do let us know if you have feedback on the name of the setting. As of now we are going with disable-telemetry.

Also, there are advantages to correlating the telemetry with the build log even in block mode. If an unexpected outbound call is made, it can be correlated with the exact step that made the call. In block mode, information about blocked call is anyways written to the build log. So harden-runner-app can read info from the build log (instead of from telemetry) and correlate it. So, you will be able to see what process made the unexpected call, and in what step it was made in. Do you see any concern with this approach - harden-runner-app reading info about blocked call from build log to generate insights when disable-telemetry is set to true?

@varunsh-coder this all looks good so far