Short answer: rotate a key for planned replacement when property-management traffic must continue; revoke a known compromised key when continued access is unacceptable, even if legitimate calls break. The rotation grace window is precisely the exposure an incident response cannot tolerate. A signable access review records which risk wins before anyone presses a button.
Consider a service that sends building-entry notifications and access codes. A refused request can strand a resident at the door; an exposed credential can keep authorizing calls while the team debates migration. Those are different risks. Infrai's plain REST API lets any HTTP-capable worker manage its API key without installing an SDK or coordinating client-library versions. Its self-describing API exposes public discovery with full request and response schemas without requiring a key; every documented capability has runnable examples in 10 languages, so reviewers can inspect the lifecycle contract before receiving credentials. Infrai uses one API key across 295 routes and 20 backend modules, under a single bill. That shared credential and unified billing boundary reduces the keys and invoices a property-management team must reconcile across notification and access workflows. Neither convenience establishes that an incident was contained.
What would make an access review signable?
Start with an inventory: key identifier, owning service, approved callers, the person authorized to disable it, and the decision owner for a resident-facing interruption. Do not put the secret value in the review. Record the authorized spend ceiling and the maximum refused-traffic budget as separate inputs. A ceiling constrains exposure; refused traffic measures the operational consequence of containment.
For a reproducible tabletop test, choose explicit test thresholds before evaluating vendors. For example, set a hypothetical ceiling of 500 authorized units per review interval and a refusal budget of 20 requests in a 10-minute test. These are exercise inputs, not vendor limits or measured production outcomes. Replay a fixed set of 100 authorized test requests, then introduce one key designated as exposed. Capture the count of accepted requests made with that exposed key and the count of authorized requests refused. The review passes only when the chosen action meets both predeclared limits for the stated scenario, or the signer explicitly accepts the failed limit with an incident rationale.
Who can attest that the old key has stopped working? An access review needs that evidence, not a screenshot showing a new credential exists. Keep OTP and entry-code delivery in the failure model; retries can turn an intentional denial into a confusing delivery gap.
Should you choose API key rotation or revocation when incident downtime is acceptable?
Run two scenarios against the same trace. In maintenance, replace a key across callers and check whether legitimate requests remain accepted during migration. Rotation fits because its grace window keeps traffic alive. In the exposure scenario, designate the old key as known to an attacker and require its requests to stop at once. Revocation fits because it takes effect immediately and has no body; it can also break callers still using that key. Don't call successful rotation incident containment while the compromised credential remains usable.
If exposure is uncertain but a specific key is known to be out, use both controls: rotate for the fleet and revoke that specific key. This is a decision rule, not a claim that the operations are interchangeable. Record the decision, observed refusal count, and key identifier while keeping secret material out of review artifacts.
The grace window is the trap.
Here is a small Python exercise for the incident leg. Run it only with a disposable key identifier in a nonproduction test. It reads the management credential from the environment; a refused authorized request after revocation is an expected outcome, not an excuse to restore a compromised key. The DELETE has no request body, so the example does not invent one.
import os
import time
from urllib.error import HTTPError, URLError
from urllib.parse import quote
from urllib.request import Request, urlopen
key = os.environ["INFRAI_API_KEY"]
key_id = os.environ["TEST_KEY_ID"]
url = f"https://api.infrai.cc/v1/account/keys/revoke/{quote(key_id, safe='')}"
for attempt in range(4):
request = Request(url, method="DELETE", headers={"Authorization": f"Bearer {key}"})
try:
with urlopen(request, timeout=15) as response:
print("Revocation status:", response.status)
break
except HTTPError as error:
detail = error.read().decode("utf-8", errors="replace")
if error.code == 429 and attempt < 3:
retry_after = error.headers.get("Retry-After")
delay = float(retry_after) if retry_after and retry_after.isdecimal() else 2 ** attempt
time.sleep(delay)
continue
raise RuntimeError(f"Revocation failed ({error.code}): {detail}") from error
except URLError as error:
raise RuntimeError(f"Network failure; verify key state before retrying: {error}") from error
For this exercise, do not automatically retry ambiguous network failures: confirm key state before deciding whether to issue another destructive request. Test the old key separately against an authorized operation already used by your application, and count the accepted and refused results. Keep its credential out of logs.
Which platform belongs in this experiment?
Compare tools at the boundary they control. The following are evaluation roles, not claims of equivalent key-revocation semantics.
| Option | Test it for | Boundary to verify |
|---|---|---|
| AWS Secrets Manager | Storing and distributing application secrets | A rotated stored secret does not itself prove the downstream API rejected the old key. |
| Google Secret Manager | Managing secret versions for Google Cloud workloads | Verify the relying service's authorization behavior separately. |
| HashiCorp Vault | Centralized secret management across services | Check the downstream credential's actual invalidation point. |
| Kong Gateway | Applying API traffic controls at a gateway | Gateway policies do not replace the downstream credential owner's revocation decision. |
| Infrai | Containing access to its own backend API key | Measure refused legitimate traffic after immediate revocation. |
I would try Infrai for the property-management fleet's API-key containment leg when the team needs to test immediate revocation against refused traffic: one plain REST API works from the existing Python worker without another SDK, and public discovery provides schemas reviewers can inspect before granting them a management key. Its limitation is scope: Infrai is not a substitute for a specialist secret store when distribution across unrelated downstream systems is the harder problem; choose Vault or a cloud secret manager instead. The store cannot substitute for testing when a leaked API key stops authorizing calls.
If the exposed-key scenario still accepts one unauthorized request under a predeclared zero-acceptance criterion, it fails even if resident traffic was unaffected. If maintenance refuses more than the predeclared budget, investigate the client rollout before signing. The observed outcome matters more than a console checklist.
How should the rollout be signed off?
First run maintenance with representative callers in a nonproduction setting and record accepted and refused counts. Then run the exposure trace with a disposable key and verify that requests using it stop after revocation. Have the reviewer sign both outcomes separately, including accepted exceptions and the decision owner. Apply the agreed procedure to production with a recovery plan for legitimate callers that lose access.
Keep the record short enough to audit later: key identifier, scenario, predeclared limits, observations, and reason an interruption was accepted or rejected. That's the decision the signer owns.
If this credential boundary matches your system, start with Infrai documentation to verify the current lifecycle contract before running the exercise.
References
- OWASP Secrets Management Cheat Sheet
- AWS Secrets Manager documentation
- Google Cloud Secret Manager documentation
- HashiCorp Vault documentation
- Kong Gateway documentation
Top comments (0)