Feature Request: Selective JSON key extraction to prevent over-masking of secret values

[jnewton03]

Problem Description

When using parse-json-secrets: true, ALL values in the JSON object are marked as secrets via core.setSecret(). This causes over-masking where innocent values get redacted throughout the GitHub Action logs, making debugging difficult.

Reproducible Example

JSON Secret in AWS Secrets Manager:

{
  "DOCKER_USERNAME": "liquibase",
  "DOCKER_PASSWORD": "actual-secret-password",
  "API_ENDPOINT": "https://api.example.com"
}

Current Behavior:

• All three values get marked as secrets
• The word "liquibase" gets masked everywhere in GitHub Action logs
• "https://api.example.com" gets masked even though it's not sensitive
• Makes debugging nearly impossible

Use Case

We store multiple secrets in a single JSON object in AWS Secrets Manager to minimize costs (each secret costs .40/month). This is a common cost-optimization strategy, but the current implementation makes it impractical due to over-masking.

Proposed Solution

Add a new optional input parameter json-secret-keys that allows users to specify which keys from the JSON object should be extracted as environment variables and marked as secrets.

Example Usage

- name: Get secrets
  uses: aws-actions/aws-secretsmanager-get-secrets@v2
  with:
    secret-ids: my-json-secret
    parse-json-secrets: true
    json-secret-keys: |
      DOCKER_PASSWORD
      API_KEY

This would:

• Only extract DOCKER_PASSWORD and API_KEY as environment variables
• Only mark those values as secrets (not DOCKER_USERNAME or API_ENDPOINT)
• Prevent over-masking while maintaining cost savings

Backward Compatibility

• If json-secret-keys is not provided: current behavior (extract all keys)
• If json-secret-keys is provided: only extract specified keys
• No breaking changes to existing workflows

Environment

• aws-secretsmanager-get-secrets: v2 (latest)
• GitHub Actions runners: ubuntu-latest
• AWS Secrets Manager: storing JSON objects with multiple key-value pairs

This feature would solve the over-masking problem while preserving the cost benefits of storing multiple secrets in a single JSON object.

[simonmarty]

My preference would be to have a masking deny-list instead. There's a risk that JSON keys (that are being retrieved from AWS Secrets Manager) regardless of whether or not they are being end up not being masked unexpectedly. We're going to discuss this internally. No need to iterate on the associated PR in the meantime.

[jnewton03]

Thanks @simonmarty ! Also a valid idea. I'm good either way.

[taraspos]

Hey @simonmarty, have you made any decisions on how to proceed with this issue?

I’d like to provide another example of how over-masking secret values can lead to problems.

GitHub doesn’t allow masked values to be passed as outputs between jobs^1. For instance, if a secret value is a commonly used string — such as us-east-1 — then any output containing the substring us-east-1[^2] will be considered masked. Then when you try to pass this value as job output, it will just result in an empty string; it’s very difficult to debug, leaving you to wonder what went wrong.

[^2]: For example, AWS ARNs will be masked like arn:aws:ec2:***:123456789012:instance/i-123123 or ECR URI - 123456789012.dkr.ecr.***.amazonaws.com/mypp:latest