Teleport gRPC API shows how NHI clients should be governed

At a glance

What this is: Teleport’s gRPC API is a management interface for dynamic cluster resources, with mTLS-based authentication and user-scoped authorization as the core control model.

Why it matters: For IAM and NHI teams, it is a concrete example of why API clients, automation tools, and operators need the same identity governance discipline as workloads and service accounts.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• 69% of organisations now have more machine identities than human ones.

👉 Read Teleport's guide to gRPC API authentication, roles, and credentials

Context

The primary issue here is not gRPC itself, but the security model around API clients that act with delegated authority. When a tool can read roles, enroll resources, or request changes inside a cluster, it is functioning as a non-human identity and should be governed with the same discipline as any other privileged automation path.

Teleport’s guidance shows a familiar pattern for NHI governance: bind client authentication to certificates, bind authorization to a specific user and role, and reduce standing privilege wherever possible. That is a sound control model, but it also exposes the operational burden of lifecycle management, especially when credentials rotate, proxies sit in the path, or multiple automation clients need separate permission boundaries. The starting position is typical for mature infrastructure teams, not exceptional.

For teams building identity controls around automation, the real question is whether the control plane can distinguish between a legitimate machine client and a misused one at runtime. The NHI risk is not the protocol alone, but the trust chain that surrounds issuance, role assignment, and credential reuse.

Key questions

Q: How should security teams govern API clients that manage cluster resources?

A: Treat them as non-human identities with their own users, roles, and credential lifecycle. Separate each automation function, scope permissions to the minimum verbs and resources, and require revocation and rotation processes that work without manual rescue when certificates change.

Q: What is the difference between authenticating an API client and authorising it?

A: Authentication proves the client is presenting valid identity material, such as a certificate. Authorisation decides what that identity may do after login, which means a valid machine credential should still be limited by role, resource, and verb.

Q: When does JIT access make more sense than standing privileges for automation?

A: JIT access makes sense when a client needs elevated access only for a narrow task or a short window. It is less useful when the workflow is continuous, but even then the underlying role should stay as narrow as possible and be recoverable through approval or automation.

Q: Why do service accounts and API clients complicate zero trust architecture?

A: Because zero trust requires continuous verification, but many automation identities are created once and then reused for long periods. Without strong rotation, ownership, and resource scoping, the machine identity becomes a durable trust assumption rather than a continuously evaluated one.

Technical breakdown

mTLS authentication for API clients and automation

Teleport’s Auth API uses mutual TLS, which means both sides of the connection present certificates and validate them before any request is accepted. In practice, this makes the client certificate the primary machine identity signal. The important detail is that certificate authenticity does not equal authorization. A valid certificate still needs to map to the correct user and role, and that mapping becomes the control point for least privilege. For automation, this is stronger than static shared secrets, but it still depends on how certificates are issued, stored, and revoked across the client fleet.

Practical implication: Treat each automation client as a distinct NHI and issue certificates with narrowly scoped trust and short lifetimes.

Role binding and minimum permissions for client actions

Once authenticated, Teleport associates the client certificate with a specific user, and that user drives authorization decisions. The article recommends a fresh user and role for each client because shared identities make attribution and containment harder. This is classic RBAC applied to machine access. The security value comes from narrowing the verbs and resources a client can touch, such as allowing read access to roles without granting broad cluster control. The failure mode is role sprawl, where convenience roles accumulate permissions until automation becomes effectively privileged.

Practical implication: Create one role per automation function and review whether each resource and verb is still necessary.

Credential loaders and dynamic identity file rotation

Teleport supports multiple credential loaders, including profile credentials, identity files, dynamic identity files, key pairs, and raw TLS credentials. The dynamic identity file pattern is the most relevant to NHI lifecycle management because it can reload credentials from disk when the underlying identity rotates. That matters when certificate rotation happens outside the client process, because stale in-memory credentials can break automation or create blind spots. The mechanism is straightforward: the client watches for refreshed identity material and re-establishes trust without manual intervention. The design reduces friction, but only if rotation is automated end to end.

Practical implication: Use reloadable identity files for automation that must survive certificate rotation without operator intervention.

Threat narrative

Attacker objective: Use a trusted automation path to modify cluster resources or widen access without triggering human login controls.

1. Entry via exposed or reused client credentials that allow a non-human client to authenticate to the Auth API.
2. Escalation through overly permissive roles, especially when multiple clients share the same user or access profile.
3. Impact when a compromised automation client can read or edit cluster resources, enroll new assets, or alter access paths.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API clients are NHIs, not just integration details. When an automation tool can authenticate, read roles, or enroll resources, it is acting as a non-human identity with delegated authority. That changes the governance model from API management to identity management. The control question is no longer whether the call succeeds, but whether the client has a distinct identity, a bounded role, and a reviewable lifecycle. Practitioners should classify these clients accordingly.

Least privilege has to start at the client boundary, not only at the resource boundary. Teleport’s recommendation to create a new user and role for each client reflects a broader NHI principle: shared identities erase accountability and expand blast radius. If a single automation identity can operate across multiple workflows, compromise of that identity becomes a platform issue rather than a task issue. Practitioners should separate client identities by function and by trust tier.

Dynamic credential reload is the right pattern, but it does not solve lifecycle debt by itself. Reloadable identity files reduce breakage during rotation, yet they still depend on issuance, storage, and revocation discipline elsewhere in the chain. That is the same trust debt seen across service accounts, API keys, and certificates in many environments. The named concept here is rotation continuity debt: when systems can renew credentials technically, but operational processes cannot keep pace. Practitioners should test rotation continuity before they standardise on any automation pattern.

Production security for machine clients should assume misuse, not just misconfiguration. The advice to avoid root, minimise sudo, and keep invitation tokens out of shell history is about reducing the damage from credential exposure and operator error. For NHI governance, that means treating client bootstrap and enrollment as high-risk events, not routine setup. Practitioners should harden the path from token issuance to first authenticated API call.

Container and orchestration integrations raise the same governance questions in a different layer. When Terraform providers, Kubernetes operators, and management CLIs all touch the same cluster, identity scope becomes harder to see and easier to overextend. That is where NHI governance fails in practice: not at the certificate layer, but at the boundary between automation convenience and access control precision. Practitioners should map every integration to a named owner, a role, and a review cycle.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means many automation identities remain difficult to inventory or review.
• The next step is to pair lifecycle control with discovery, using NHI Lifecycle Management Guide to reduce the time between issuance, rotation, and revocation.

What this signals

Rotation continuity debt: teams often automate certificate refresh technically, but fail to align that automation with ownership, review, and revocation. In practice, that leaves machine clients trusted longer than intended even when the tooling supports short-lived credentials.

The broader programme implication is that API clients, Kubernetes operators, and infrastructure automation need explicit identity classification. If they can enroll resources or read privileged objects, they belong in the same governance inventory as service accounts and other NHIs. For baseline controls, align the programme with OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs, the risk is not theoretical. Teams should expect bootstrap paths, not just runtime paths, to be part of the attack surface and plan controls accordingly.

For practitioners

• Assign a unique identity to each automation client Create separate users and roles for each gRPC client, Terraform workflow, and operator path so actions remain attributable and blast radius stays bounded.
• Use minimum-permission roles for every machine workflow Grant only the read, write, or enroll permissions a specific client needs, and avoid broad built-in roles that can touch all cluster resources.
• Adopt reloadable identity files for rotation continuity Use dynamic identity files where rotation must happen without restarting clients, then test that the client can recover cleanly after certificate refresh.
• Remove bootstrap tokens from interactive shells Save invitation tokens to files or protected automation paths instead of entering them directly on the command line, where shell history can expose them.
• Harden privileged access paths for cluster automation Run services as non-root unless root is required, limit sudo, and treat any workflow that can enroll resources as a privileged access path.

Key takeaways

• API clients that manage infrastructure should be treated as non-human identities with distinct ownership, scope, and lifecycle control.
• mTLS improves trust in the connection, but role design and credential rotation determine whether the identity can be safely governed.
• The operational risk sits in the gap between certificate support and real revocation discipline, especially when multiple automation paths share access.

Key terms

• Non-Human Identity: A non-human identity is a digital identity used by software rather than a person, such as a service account, API key, token, certificate, workload, or agent. In practice, these identities can authenticate, authorize, and access systems, so they need ownership, lifecycle management, and review just like human accounts.
• Mutual TLS: Mutual TLS is a connection method where both client and server present certificates and verify each other before communication is allowed. For machine identities, it is a strong authentication pattern, but it does not replace authorization, rotation, or revocation controls, which still determine what the client may do.
• Dynamic Identity File: A dynamic identity file is a credential file that can be reloaded from disk when the underlying identity changes. It is useful for automation that must keep running through certificate rotation, but it only works well when issuance, storage, and refresh processes are also controlled.
• Role-Based Access Control: Role-Based Access Control assigns permissions to named roles and then associates identities with those roles. For machine access, it helps separate duties and reduce blast radius, but it only works when roles are narrowly defined and regularly reviewed for privilege creep.

What's in the full article

Teleport's full guide covers the operational detail this post intentionally leaves for the source:

• Credential loader selection guidance for profile, identity file, dynamic identity file, key pair, and TLS modes.
• Client connection patterns when the Auth Service sits behind a Proxy Server or reverse tunnel.
• Practical examples for creating roles, signing identities, and starting clients with the correct credentials.
• Trade-offs between usability, customisability, and SSH support across different credential types.

👉 Teleport's full guide covers credential loaders, reverse tunnels, and client connection options.

Deepen your knowledge

API client identity, certificate rotation, and least-privilege role design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team manages automation through gRPC, operators, or infrastructure clients, this is a practical place to start.