OpenHands icon indicating copy to clipboard operation
OpenHands copied to clipboard

[Resolver] Support custom env vars for Openhands agents

Open malhotra5 opened this issue 1 year ago • 0 comments

End-user friendly description of the problem this fixes or functionality that this introduces

  • [ ] Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below

Give a summary of what the PR does, explaining any non-trivial design decisions

This PR allows users to pass custom env variables to the openhands runtime. This is tough to achieve in Github actions natively as Github doesn't allow for dynamic manipulation of secrets. How this PR works -

  1. User creates a repo secret with the prefix OPENHANDS_ENV_
  2. ALL secrets are passed to the reusable workflow
  3. Secrets are filtered by prefix OPENHANDS_ENV_ and replaced with SANDBOX_ENV_ (this allows openhands agents to have access to env vars in its runtime)

Pros/Cons

This is quite simple for the user to setup. The downside is ALL secrets are passed to the reusable workflow, which isn't ideal in terms of granularity.

Sample Test

Issue addressed - This issue requires openhands to run an api with the custom env variable. Openhands would fail unless the env var exists in its runtime. Workflow logs

Alternative approaches

1: Filter before sending

  1. The caller workflow would require a separate job to filter secrets by prefix (the "env job")
  2. The caller would encrypt the secrets
  3. env job would pass the encrypted value (through its output, which makes the encrypted value visible) to the job which invokes the reusable workflow
  4. The reusable workflow is invoked with the encrypted secrets
  5. Reusable workflow will decrypt the secrets and pass them to Openhands

We need an encryption scheme as github actions don't support a native way to pass secrets between jobs (and filtering secrets cannot be performed inside the job calling the reusable workflow).

I'm thinking symmetric key encryption using GNU Privacy Guard would work to achieve this. The user would need to perform just one additional step to setup a PASSPHRASE in their repo secrets.

2: Key store

Add support for custom env vars via integrations to external key stores. For example, AWS Secrets Key manager.


Link of any specific issues this addresses #5132

malhotra5 avatar Nov 21 '24 00:11 malhotra5