fix: source aware api-key flag + redact api key value from logging

[nborges-aws]

Description

Expand api-key-credential-provider create/update operations with full source-aware flag surface.

Changes:

• Source-aware --api-key: accepts inline values, file://path, or stdin so credentials never appear in shell history
• External secrets: --api-key-secret-arn + --api-key-secret-json-key for existing Secrets Manager entries
• Mutual exclusivity: --api-key and the pair of external secret cannot be mixed; the secret pair requires both values
• Tags: --tags on create (JSON object)
• Sensitive flag: --api-key marked sensitive so values are redacted from debug logs
• readSource / readSourceText utility for source-aware flag values. Follows @aidandaly24 pattern for runtime invoke, but moved to shared location and adds convenience method for decoding to text value.
• added unit tests for source utilities, and mutual exclusivity tests for source-aware create/update identity
• updated fixture tests after latest changes

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 96.59091% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.84%. Comparing base (272e50e) to head (d006bef).

Files with missing lines	Patch %	Lines
...ntity/api-key-credential-provider/update/index.tsx	93.02%	3 Missing ⚠️
src/handlers/source.tsx	94.11%	2 Missing ⚠️
src/handlers/utils.tsx	96.29%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           refactor    #1819    +/-   ##
==========================================
  Coverage     94.84%   94.84%            
==========================================
  Files           143      145     +2     
  Lines          7120     7262   +142     
==========================================
+ Hits           6753     6888   +135     
- Misses          367      374     +7     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[aidandaly24]

This advertises repeatable key=value tags or a JSON object, but z.string() plus parseJsonFlag only accepts one JSON value. For example, --tags env=prod currently fails as invalid JSON. Could we implement and test both documented forms, including validating that the JSON form is a string map?

[aidandaly24]

In the doc discussion, the preferred external-secret representation was one structured-reference flag rather than separate ARN and JSON-key flags. Could we use something like --api-key-secret-reference '{"secretId":"...","jsonKey":"..."}' for create/update, mutually exclusive with --api-key? We should also have a successful external-reference request-mapping test, I think the current tests only cover invalid combinations.

Update should first retrieve the provider and preserve its existing apiKeySecretSource. A MANAGED provider should accept only --api-key, while an EXTERNAL provider should accept only the structured secret reference. I think we should reject mismatched input locally and test both directions instead of deriving the source mode from the supplied flags.

[aidandaly24]

I already implemented a version of source-aware input on another branch and I think it has some features we can use. Can we use that implementation (pasted below) as the shared behavior? The shared reader should remain byte-oriented so Runtime payloads are not decoded, while text-only credentials use strict UTF-8 decoding:

import { readFile } from "node:fs/promises";
import { addAbortSignal } from "node:stream";
import { buffer } from "node:stream/consumers";

export async function readSource(
  source: string,
  stdin?: NodeJS.ReadStream,
  signal?: AbortSignal,
): Promise<Uint8Array> {
  signal?.throwIfAborted();

  if (source.startsWith("file://")) {
    const path = source.slice("file://".length);
    try {
      return await readFile(path, { signal });
    } catch (error) {
      if (error instanceof Error && error.name === "AbortError") throw error;
      throw new TypeError(`unable to read source file: ${path}`);
    }
  }

  if (source !== "-") {
    return new TextEncoder().encode(source);
  }
  if (!stdin) {
    throw new TypeError("stdin is not available for this source");
  }

  return buffer(signal ? addAbortSignal(signal, stdin) : stdin);
}

export async function readSourceText(
  source: string,
  stdin?: NodeJS.ReadStream,
  signal?: AbortSignal,
): Promise<string> {
  const bytes = await readSource(source, stdin, signal);
  try {
    return new TextDecoder("utf-8", { fatal: true }).decode(bytes);
  } catch {
    throw new TypeError("source must contain valid UTF-8");
  }
}

Runtime can import these functions while retaining its request-specific dual-stdin validation. Identity can use readSourceText for --api-key. What do you think? I can also make the change in my Runtime invoke PR so not a problem really just a suggestion.

[AlexanderRichey]

Want to merge in @nborges-aws code first and then add yours on top @aidandaly24 ? The signatures are identical, so this shouldn't cause any conflicts.

[aidandaly24]

Yup that works for me

[AlexanderRichey]

Looks good! Only one blocking comment about using types over interfaces as input objects in Core, in the given context.

[AlexanderRichey]

I think these should be types and not interfaces. Types hold values whereas interfaces are more abstract and don't have a concrete existence on their own—they need to be implemented by something else.

Would it make sense to import the types directly from the AWS SDK? That's what we did when defining the harness and runtime types. This will make the code a bit easier to maintain over time, I think.

[AlexanderRichey]

Want to merge in @nborges-aws code first and then add yours on top @aidandaly24 ? The signatures are identical, so this shouldn't cause any conflicts.

[aidandaly24]

Thanks for making the update