Add json-secret-keys parameter for selective JSON key extraction - #264
Open
jnewton03 wants to merge 1 commit into
Open
Add json-secret-keys parameter for selective JSON key extraction#264jnewton03 wants to merge 1 commit into
jnewton03 wants to merge 1 commit into
Conversation
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>
|
Running into this now. Yes please! |
|
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>
This was referenced Aug 28, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds a new optional
json-secret-keysparameter 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 viacore.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-keysparameter allows selective extraction:This would only extract and mask the
passwordandapi_keyvalues, leaving other non-sensitive values likeusernameandhostunmasked.Key Features
json-secret-keysis not provided, all keys are extracted (existing behavior)Changes Made
json-secret-keysinput parameter toaction.ymlinjectSecret()function inutils.tsto support selective key filteringindex.tsto read and pass the new parameterTesting
dist/directoryExamples
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
passwordvalue gets maskedusername,host,portremain visible in logs for debuggingFixes #263
🤖 Generated with Claude Code