Skip to content

Add json-secret-keys parameter for selective JSON key extraction - #264

Open
jnewton03 wants to merge 1 commit into
aws-actions:mainfrom
jnewton03:main
Open

Add json-secret-keys parameter for selective JSON key extraction#264
jnewton03 wants to merge 1 commit into
aws-actions:mainfrom
jnewton03:main

Conversation

@jnewton03

Copy link
Copy Markdown

Summary

This PR adds a new optional json-secret-keys parameter that allows users to specify which keys from JSON secrets should be extracted as environment variables. This solves the over-masking problem where ALL values in JSON secrets get marked as secrets, making debugging nearly impossible.

Problem Description

When using parse-json-secrets: true, all JSON values are marked as secrets via core.setSecret(), causing over-masking where innocent values like usernames, hostnames, and API endpoints get redacted throughout GitHub Action logs.

Example: A JSON secret containing {"DOCKER_USERNAME": "liquibase", "DOCKER_PASSWORD": "secret123"} would mask the word "liquibase" everywhere in logs, making debugging very difficult.

Solution

The new json-secret-keys parameter allows selective extraction:

- name: Get secrets with selective key extraction
  uses: aws-actions/aws-secretsmanager-get-secrets@v2
  with:
    secret-ids: database/credentials
    parse-json-secrets: true
    json-secret-keys: |
      password
      api_key

This would only extract and mask the password and api_key values, leaving other non-sensitive values like username and host unmasked.

Key Features

  • Backward Compatible: If json-secret-keys is not provided, all keys are extracted (existing behavior)
  • Flexible: Supports both simple and nested JSON structures
  • Cost-Effective: Maintains the cost benefit of storing multiple secrets in one JSON object
  • Selective Masking: Only specified values are marked as secrets, reducing over-masking

Changes Made

  • Added json-secret-keys input parameter to action.yml
  • Modified injectSecret() function in utils.ts to support selective key filtering
  • Updated index.ts to read and pass the new parameter
  • Added comprehensive unit tests covering various scenarios
  • Added integration tests for the new functionality
  • Updated README.md with parameter documentation and usage examples

Testing

  • ✅ All existing tests pass (maintaining backward compatibility)
  • ✅ New unit tests cover selective key extraction scenarios
  • ✅ Integration tests verify end-to-end functionality
  • ✅ Test coverage maintained at 98.75% statements, 98.55% branches
  • ✅ Linting passes without errors
  • ✅ Build successfully updates dist/ directory

Examples

Before: All JSON values get masked, making debugging difficult

{
  "username": "admin",        // Gets masked everywhere
  "password": "secret123",    // Gets masked (correctly)
  "host": "db.example.com",   // Gets masked everywhere  
  "port": "5432"              // Gets masked everywhere
}

After: Only sensitive values get masked

json-secret-keys: |
  password
  • ✅ Only password value gets masked
  • username, host, port remain visible in logs for debugging

Fixes #263

🤖 Generated with Claude Code

This feature allows users to specify which keys from JSON secrets should be
extracted as environment variables, preventing over-masking of non-sensitive
values like usernames, hostnames, and ports.

Key changes:
- Add json-secret-keys input parameter to action.yml
- Modify injectSecret() function to support selective key filtering
- Add comprehensive unit and integration tests
- Update README.md with parameter documentation and examples

Fixes over-masking issue where all JSON values were marked as secrets,
making debugging difficult when innocent values got redacted in logs.

Fixes aws-actions#263

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
@jnewton03
jnewton03 requested a review from a team as a code owner September 10, 2025 19:42
@sc250024

Copy link
Copy Markdown

Running into this now. Yes please!

@strike

strike commented Jan 13, 2026

Copy link
Copy Markdown

What are we waiting for?

jandroav added a commit to liquibase/liquibase that referenced this pull request Aug 17, 2026
…OPS-1048)

Follow-up to the CodeRabbit finding on credential scoping. /vault/liquibase is
a single shared secret and the action can only load it whole, so
parse-json-secrets exports the DigiCert KeyLocker credentials into every job
that wants GPG. aws-actions/aws-secretsmanager-get-secrets#264 would let us
request a subset, but it has been open since Sep 2025 and ships in no release
(v3.0.1 is current), so blank the signing fields instead wherever the job
cannot sign:

- create-release.yml `reversion`: never signs at all — cleared unconditionally.
- create-release.yml `build-installers`: cleared when dry_run is true, the path
  whose signing steps are already gated off.
- installer-build-check.yml: KeyLocker steps were removed from this workflow, so
  it is now GPG-only — cleared unconditionally.

Also drops the five redundant `${{ env.SM_* }}` re-exports in "Set Environment
Variables for Signing": the vault action already put those values in the job
environment, so the step was copying them onto themselves and expanding five
more secrets into a generated shell script. Only SM_CLIENT_CERT_FILE, which
points at the decoded cert, actually needed setting.

All seven SM_* names referenced anywhere in the repo are KeyLocker fields, so
the SM_-prefix sweep has no collateral. Fully scoping this still wants a
separate GPG-only secret in Secrets Manager.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
jandroav added a commit to liquibase/liquibase that referenced this pull request Aug 18, 2026
…rom installer-build-check (#7912)

* feat(ci): gate DigiCert KeyLocker signing in create-release.yml, drop it from installer-build-check.yml

create-release.yml: gate the two KeyLocker signing steps (Sign Windows
Installer, Verify Windows Installer Signature) and the credential-prep
steps (cert decode, env vars, jsign/osslsigncode install, KeyLocker client
tools) behind `if: ${{ inputs.dry_run == false }}`, matching the idiom
already used elsewhere in this file (lines 188, 358, 385). A dry-run
release now builds and publishes an unsigned installer to the dry-run
draft release and consumes zero KeyLocker signatures.

installer-build-check.yml: remove the KeyLocker signing and verification
steps entirely, along with their credential-prep steps. This workflow
("Build Test Installers") exists to confirm the installer builds, not
that it signs; it has run twice, both failures, and gating behind an
opt-in input would be more machinery than the workflow is worth.

Why: 90% of the shared 1000-signature DigiCert KeyLocker pool was
consumed by builds that never ship (TECHOPS-1048). This mirrors the same
gate landing in liquibase/liquibase-pro's build-secure-distribution.yml.

Jira: https://datical.atlassian.net/browse/TECHOPS-1048

Co-Authored-By: Mandalorian (Claude) <noreply@anthropic.com>

* fix(ci): read KeyLocker cert from job env instead of template expansion (TECHOPS-1048)

CodeRabbit/zizmor flagged template-injection on the Decode Client
Authentication Certificate step: `${{ env.SM_CLIENT_CERT_FILE_B64 }}` is
expanded into the generated shell script. "Get secrets from vault" already
exports the field into the job env via parse-json-secrets, so reading
"$SM_CLIENT_CERT_FILE_B64" is the same value with no expansion. Also swaps
echo for printf '%s' so no trailing newline reaches base64 --decode.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(ci): keep KeyLocker credentials out of jobs that never sign (TECHOPS-1048)

Follow-up to the CodeRabbit finding on credential scoping. /vault/liquibase is
a single shared secret and the action can only load it whole, so
parse-json-secrets exports the DigiCert KeyLocker credentials into every job
that wants GPG. aws-actions/aws-secretsmanager-get-secrets#264 would let us
request a subset, but it has been open since Sep 2025 and ships in no release
(v3.0.1 is current), so blank the signing fields instead wherever the job
cannot sign:

- create-release.yml `reversion`: never signs at all — cleared unconditionally.
- create-release.yml `build-installers`: cleared when dry_run is true, the path
  whose signing steps are already gated off.
- installer-build-check.yml: KeyLocker steps were removed from this workflow, so
  it is now GPG-only — cleared unconditionally.

Also drops the five redundant `${{ env.SM_* }}` re-exports in "Set Environment
Variables for Signing": the vault action already put those values in the job
environment, so the step was copying them onto themselves and expanding five
more secrets into a generated shell script. Only SM_CLIENT_CERT_FILE, which
points at the decoded cert, actually needed setting.

All seven SM_* names referenced anywhere in the repo are KeyLocker fields, so
the SM_-prefix sweep has no collateral. Fully scoping this still wants a
separate GPG-only secret in Secrets Manager.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Mandalorian (Claude) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

3 participants