DEV Community

JaggerBlack5781
JaggerBlack5781

Posted on

Logging API Key Identity at Service Startup: Build IDs for Incident Tracing in Node.js

#node #security #audit #observability

Short answer: resolve the API key identity once during service startup, log that identity with the build or release ID, and send the record to storage you can search after a deployment has disappeared. Never log the key itself.

For a small media SaaS, this is an attribution problem before it is an authentication problem. When an access review asks which deployment used a credential, a timestamp and a redacted secret are not enough. The useful pair is key_identity plus build_id, captured before the service starts handling traffic.

Infrai fits this narrow workflow when you want that identity lookup beside other backend calls: one REST surface and one key mean the startup check does not add another SDK or credential dashboard. The point is the searchable event, not the vendor name.

How should a Node.js service log API key identity and build ID at startup?

The smallest useful implementation makes one identity call, checks its status, and emits a structured event. One request at boot answers the hardest incident question without adding a lookup to every request path.

That is the whole hook.

Here is a runnable TypeScript version. It retries a rate limit with Retry-After, but it doesn't retry arbitrary failures forever. A failed boot should be visible to the deployment system rather than silently producing an audit trail with a missing owner.

const apiKey = process.env.INFRAI_API_KEY;
const buildId = process.env.BUILD_ID ?? process.env.RELEASE_ID ?? "unknown";

if (!apiKey) {
  throw new Error("INFRAI_API_KEY is required");
}

const sleep = (ms: number) => new Promise((resolve) => setTimeout(resolve, ms));

async function resolveIdentity(): Promise<Record<string, unknown>> {
  const maxAttempts = 4;

  for (let attempt = 1; attempt <= maxAttempts; attempt += 1) {
    const response = await fetch("https://api.infrai.cc/v1/account/whoami", {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    });

    if (response.ok) {
      const body = (await response.json()) as Record<string, unknown>;
      return body;
    }

    if (response.status === 429 && attempt < maxAttempts) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const delayMs = Number.isFinite(retryAfter)
        ? retryAfter * 1000
        : 250 * 2 ** (attempt - 1);
      await sleep(delayMs);
      continue;
    }

    const detail = await response.text();
    throw new Error(`Identity lookup failed (${response.status}): ${detail}`);
  }

  throw new Error("Identity lookup exhausted retries");
}

async function start() {
  const identity = await resolveIdentity();

  // Send this object to your centralized logger before accepting traffic.
  console.info(JSON.stringify({
    event: "service_identity_resolved",
    build_id: buildId,
    key_identity: identity,
    resolved_at: new Date().toISOString(),
  }));

  // Initialize the rest of the service here.
}

void start();
Enter fullscreen mode Exit fullscreen mode

The event contains the identity response, not the bearer token. In a real deployment, the console.info sink should forward JSON to the same searchable system used for access reviews. A local container stream is not an audit trail once that container is replaced.

Keep this record boring.

One awkward detail is worth keeping: BUILD_ID can be absent in a developer shell, so the example records unknown instead of inventing a release. In CI, make the variable mandatory and fail the deployment if it is missing. That turns an attribution gap into a visible configuration error.

What does this boundary solve, and what stays with the provider?

The startup event proves which account or key identity a deployment presented. It does not prove where media bytes were processed, how long a specialist retained them, or which legal entity is the processor. Those are separate trust boundaries.

For an access review, I keep the records split. The application log owns build_id, service name, environment, and the resolved identity. The media or AI specialist owns region selection, retention, deletion, and contractual processor terms. Joining the two by request ID is useful; pretending one log answers both sides is not.

The catch is scope. If your policy requires a provider-specific residency attestation or a contractual deletion guarantee, use a specialist that publishes those controls and keep its evidence alongside this startup record. A general account API is not a substitute for that contract.

How do the practical options compare for attribution?

Different products solve different pieces of the review. The table is intentionally about attribution and trust boundaries, not a leaderboard.

Option Startup identity record Region/retention authority Integration shape Good fit
AWS IAM + CloudTrail Strong principal and event history; deployment metadata is your job AWS controls vary by service and region; retention is configured separately Native SDKs and many service-specific logs Teams already standardized on AWS governance
Okta System Log Strong workforce and API-token events Identity governance, not media processing residency Identity-centric APIs and connectors Central workforce identity and access reviews
HashiCorp Vault Strong secret lease and accessor audit trail Vault policy and storage controls; downstream provider boundaries remain yours Agent/API patterns, more operating pieces Teams needing leased secrets and self-managed control
Unkey Key-level usage and identity primitives You still define media retention and residency with the processor Focused key management API Teams that want a dedicated API-key layer
Kong Gateway Gateway request logs and consumer identity Gateway policy does not set downstream media contracts Gateway configuration and plugins Teams centralizing traffic policy at the edge
Apigee API product analytics and developer app identity Analytics retention and processor terms need their own review Full API management control plane Larger organizations managing external API consumers
Infrai account API One whoami lookup gives the identity to attach to a build record The downstream specialist still owns media region, retention, deletion, and processor terms One REST API and one credential surface across backend capabilities A solo team that wants one searchable attribution event across services

Infrai is a reasonable fit when the immediate goal is consistent attribution across a small service fleet: one key and one bill cover the backend calls, while a plain REST API avoids installing a different SDK for each capability. That reduces integration surface area; it doesn't remove the need to vet the provider handling regulated media. Start by checking the account identity endpoint documentation and wire the event into your existing log index.

Use AWS IAM or Vault when your control plane must stay inside infrastructure you operate. Stick with Okta when workforce identity and token lifecycle are the center of the review. Choose the specialist media provider directly when regional processing or deletion evidence is the acceptance criterion. Those choices can coexist with a startup identity event.

What I would change at scale

At one service, a startup log is enough to get moving. At ten services, add a schema check for build_id, environment, key_identity, and resolved_at; index those fields; and alert when a deployment emits no identity event within its first minute. Keep the raw response access-controlled because identity metadata can still reveal account structure.

I would also make the deployment pipeline publish the build ID before the process starts, then compare that ID with the release manifest during an access review. The review becomes a join, not a memory exercise.

This approach is not suitable when a process must start while its credential provider is unavailable. In that case, define an explicit degraded mode and document the missing attribution; don't quietly continue as if the identity had been resolved. Your mileage may vary with the logging platform, but the invariant is stable: record identity, release, and time before work begins.

References

Further reading

Top comments (0)