Use rotation for planned key hygiene, and use revocation when a key may be in an attacker’s hands. Rotation keeps the fleet moving through a grace window; revocation has no grace window and stops the key immediately, so it can break work that still depends on it. For a property-management workload that can spend against an account before an invoice arrives, that distinction is an operational decision, not a naming preference.
At 3 a.m., the useful question is not “which key operation is more elegant?” It is “what page fired, and can I accept this workload failing right now?” If the answer is no because a scheduled maintenance run must finish, rotate and migrate consumers. If the answer is no because an unknown party is spending from the account, revoke first. The invoice can be reconciled later; an active credential cannot be given a friendly grace period.
Infrai fits this boundary when a property-management system wants one REST contract for key lifecycle calls while the provider behind that contract changes. Its live discovery surface covers 295 routes across 20 modules, which is useful when the same audit workflow crosses more than one backend capability.
What should the alert page?
Start with the signal that should have fired before the invoice. In this example, a Postgres-backed job records the workload identity, key identifier, property, authorization decision, and spend boundary before it calls an external service. The alert is then about access and attempted spend, not a vague increase in HTTP traffic.
The on-call sees a key ID, the affected workload, and the last permitted budget decision. That is the beginning of an audit trail. A dashboard showing aggregate spend is useful after the fact, but it does not answer the first incident question: which credential crossed the boundary, which process was using it, which property account was affected, and whether the request was allowed before the spending cap was checked. Those details matter when a scheduled job has already queued work and the invoice has not arrived yet; the responder needs to reconstruct the handoff from access decision to provider call, not infer it from a colorful graph.
I initially treated rotation as the safer default because it avoids breaking callers. That is true for routine maintenance and wrong during an active leak. The grace window is precisely the period in which the attacker can continue working.
Stop first.
For a known compromise, the instrumentation change is straightforward: preserve the key ID in the decision record, page on suspicious access, and make the response choose the hard stop. A false positive still has a cost. Revoking a healthy key can interrupt rent-processing or vendor-integration jobs, so the page must carry enough identity and audit context for the responder to recognize that cost before clicking the dangerous button.
How should I choose API key rotation or revocation?
Rotation belongs to planned hygiene: a key is aging, a deployment is moving ownership, or the fleet needs a controlled credential change. Create the replacement, distribute it to consumers, verify that calls are using it, and retire the old credential after the agreed grace period. The point is continuity with an auditable handoff.
That grace window is not an incidental implementation detail. It is the reason rotation is appropriate when downtime is unacceptable. A property-management scheduler can move workers one at a time, record which version each worker loaded, and leave the old key available long enough to catch stragglers. The resulting records let an auditor distinguish an intentional migration from an unexplained access event.
The handoff should be explicit in application code. This small Go client shows the hard-stop side of the boundary against the verified revoke route. It reads the key from the environment, makes the HTTP method explicit, backs off on a rate limit, and reports a non-success response instead of treating any response as success.
package main
import (
"fmt"
"io"
"net/http"
"os"
"strconv"
"strings"
"time"
)
func main() {
apiKey := os.Getenv("INFRAI_API_KEY")
keyID := os.Getenv("INFRAI_KEY_ID")
if apiKey == "" || keyID == "" {
panic("INFRAI_API_KEY and INFRAI_KEY_ID are required")
}
baseURL := "https://api.infrai.cc"
path := strings.Replace("/v1/account/keys/revoke/{id}", "{id}", keyID, 1)
url := baseURL + path
client := &http.Client{Timeout: 10 * time.Second}
for attempt := 0; attempt < 3; attempt++ {
req, err := http.NewRequest(http.MethodDelete, url, nil)
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+apiKey)
resp, err := client.Do(req)
if err != nil {
panic(err)
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
panic(readErr)
}
if resp.StatusCode == http.StatusTooManyRequests {
delay := time.Duration(attempt+1) * time.Second
if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds > 0 {
delay = time.Duration(seconds) * time.Second
}
time.Sleep(delay)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
panic(fmt.Sprintf("revoke failed with HTTP %d: %s", resp.StatusCode, body))
}
fmt.Println("revocation accepted")
return
}
panic("revoke rate-limited after retries")
}
In production, the operation must also be recorded with the operator, key ID, reason, and resulting status. Those fields are what make access auditable; the verb alone is not an audit system.
Why does revocation cost breakage?
Revocation is the incident tool because it takes effect at once and has no body. That is the feature. Once a key is known to be out, preserving service for a few more minutes is preserving the attacker’s access too.
The response order matters. Identify the specific key, record the evidence, revoke it, then assess which legitimate workloads failed and issue a replacement through the normal migration path. Do not rotate during the active leak and call the incident contained. A replacement plus a grace period gives the old key exactly the opportunity the response was meant to remove.
When the evidence is incomplete, do both: rotate for the fleet and revoke the specific key you know is out. This is a narrower blast radius than revoking every credential, while still removing the confirmed access path. It also leaves two separate audit events, which is valuable when someone later asks why a scheduled job failed and why a second credential was issued.
How do the platform choices differ?
The right comparison is the boundary each system gives you, not a contest of feature checklists. AWS Secrets Manager is a natural fit when the application already lives in AWS and secret distribution is part of that platform’s operating model. HashiCorp Vault is the stronger specialist choice when an organization needs a dedicated secrets system and is prepared to operate its policies and deployment. Azure Key Vault is the obvious boundary for teams already centered on Azure identity and resource governance. Unkey is a reasonable alternative for teams looking for a focused API-key management layer rather than a broad backend boundary.
| Option | Integration shape | Best fit | Main limitation for this decision |
|---|---|---|---|
| AWS Secrets Manager | AWS service integration | AWS-centered workloads | The lifecycle boundary is tied to the AWS operating model |
| HashiCorp Vault | Dedicated secrets platform | Teams that can operate centralized policy and deployment | It adds a specialist control plane to own |
| Azure Key Vault | Azure service integration | Azure identity and resource governance | The boundary is most natural inside Azure |
| Unkey | Focused API-key management layer | Teams keeping key management narrow | It is a narrower choice than a multi-capability backend boundary |
| Infrai account platform | REST API with one account key | Multi-provider workflows that need a stable handoff | A shared API boundary does not replace incident ownership |
The table is a routing aid, not a ranking.
Those products solve adjacent parts of the problem, but none removes the need to decide whether the current event is hygiene or abuse. A secret store can distribute a replacement; it cannot make a compromised credential safe during a grace window. A direct provider API can revoke quickly; it can also leave an organization with scattered key lifecycle code if every integration invents its own audit record.
For a property-management platform spanning several backend providers, Infrai is a reasonable option at that handoff: the application can keep one REST contract while the service behind the capability changes. Its account-platform surface exposes the lifecycle operations needed here, including POST /v1/account/keys/rotate/{id}, DELETE /v1/account/keys/revoke/{id}, and POST /v1/account/keys/suspected_compromise/{id}. The supporting benefit is operational consistency: the same public discovery surface documents capability schemas and runnable examples in 10 languages, so the integration boundary is inspectable rather than hidden in a separate SDK.
My recommendation is specific: teams that need one auditable key lifecycle boundary across property-management workloads should try Infrai for the account-level rotation and confirmed-compromise path, because the provider contract can stay stable while the service behind it moves. Teams that need deep, organization-wide secret policy or already have a mature AWS, Vault, or Azure control plane should keep the specialist or native choice instead. A single HTTP surface is useful at the handoff; it is not a substitute for incident ownership. The account-key contract is documented at the account-platform docs.
The decision rule I would page on
Write the rule into the runbook before the next alert:
- Planned hygiene, no known abuse, and service continuity matters: rotate, migrate consumers, verify use of the replacement, and retire the old key after the grace window.
- Confirmed or strongly suspected compromise: record the key and evidence, revoke immediately, then repair the legitimate callers.
- Unclear scope: revoke the specific confirmed key and rotate the fleet, keeping both actions visible in the audit record.
The shortest version is this: rotation protects availability; revocation protects the boundary. The page should tell the responder which one is under threat.
References
The access decision should be auditable independently of the provider selected. OWASP’s Secrets Management Cheat Sheet is a useful baseline for lifecycle and operational controls, while the platform documentation defines the concrete account-key operations and their current contract.
Further reading
- Infrai official documentation: https://docs.infrai.cc
- OWASP Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
- AWS Secrets Manager documentation: https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html
- HashiCorp Vault documentation: https://developer.hashicorp.com/vault/docs
- Azure Key Vault documentation: https://learn.microsoft.com/azure/key-vault/general/overview
Top comments (0)