toolkit Support secret inheritence `secrets: inherit` for actions

Hi,

Reusable workflow supports secrets: inherit, this allows the author of the workflow to access secrets set by the configuration without the calling workflow aware of the internals of the reusable workflow it calls. It makes it easy to maintain a changing environment in which callable workflows evolve and use more secrets.

I am aware that the initial design of actions assumed secrets are provided as environment and/or input parameters. However, both methods require the caller to be aware of the implementation of the action. For composite actions which wraps a reusable code into an action it makes it difficult to maintain as the secrets must be provided explicitly via input or via environment.

Please consider to support the secrets collection in actions as well, this will explicitly mark the secret data to be masked/encrypted, and will allow inheritance similar to reusable workflows and achieve consistency.

In short, the secrets handling in actions should be similar to the secrets handling of the workflows (input object, input mask, inherit).

Workaround

workflow

      - uses: ./.github/actions/xxx
        with:
          secrets: ${{ toJSON(secrets) }}

action.yaml

inputs: 
  secrets:
    description: 'Secrets toJSON'
<snip>
runs: 
  using: "composite"
  steps:
    - uses: xxx
      with:
        xxx: ${{ fromJSON(inputs.secrets).SECRET1 }}

Expected (Inheritance)

workflow

      - uses: ./.github/actions/xxx
        secrets: inherit

action.yaml

<snip>
runs: 
  using: "composite"
  steps:
    - uses: xxx
      with:
        xxx: ${{ secrets.SECRET1 }}

Expected (Explicit)

workflow

      - uses: ./.github/actions/xxx
        secrets:
          SECRET1: xxx

action.yaml

<snip>
secrets: 
  SECRET1:
    description: 'Secret1'
<snip>
runs: 
  using: "composite"
  steps:
    - uses: xxx
      with:
        xxx: ${{ secrets.SECRET1 }}

Aug 27 '22 15:08 alonbl

I am also dealing with issues related to to this. It complicates the workflow quite a bit.

Dec 06 '22 18:12 nexocentric

Looking forward to this. It increases complexity without adding any additional security for local actions.

Dec 21 '22 16:12 undergroundwires

I agree that this would be very helpful. For example, we have encapsulated some logic in a Composite Action and now want to enhance it with a non-breaking change that requires access to a secret key that we can add to the org secrets. This is not possible without changing all places that call this Action. This breaks the encapsulation and requires impacting all callers of the custom action.