They should govern access at the cloud control plane and not depend on a single network proxy to cover every service type. Native API integration is the practical test: if a control cannot reach the resource type directly, it is not suited to modern cloud operations.
How should IAM teams treat cloud access when Kubernetes, serverless and SaaS are all in play?
The first job is to treat each access path as a first-class cloud control problem, not as a network-routing problem with a single choke point. Kubernetes, serverless platforms and SaaS each expose different authorization surfaces, trust boundaries and token flows, so access governance has to follow the resource type, not the transport path.
That means the IAM team should design for native control-plane integration wherever possible, because that is what allows policy, identity context and auditability to follow the workload or service directly.
Why a single proxy model breaks down across modern cloud services
A central proxy can still be useful for some traffic, but it stops being a complete answer once access spans cluster APIs, function runtimes and SaaS tenants. Kubernetes traffic is often mediated by the orchestrator, serverless access may be mediated by platform roles and event-driven permissions, and SaaS access is usually exposed through provider-native APIs and application-specific authorization rules.
If the control layer cannot speak the service’s native language, it cannot reliably express least privilege, session scope, or object-level policy. In practice, that leaves teams with either over-broad access or blind spots where the control can see traffic but cannot govern the operation that matters. Native cloud workload identity guidance is especially relevant here, because it shows how modern platforms are already built around direct trust relationships rather than a universal proxy pattern: Cloud Workload Identity Guide.
For Kubernetes specifically, the access problem is usually compounded by the separation between cluster administration, namespace-level authorization and workload-to-service calls. For SaaS, the problem is often different: the important control is not where the packet came from, but which tenant object, record or API scope the caller can reach. In both cases, the IAM design has to preserve the original identity context long enough for the target system to make its own authorization decision.
What good cloud IAM design looks like across Kubernetes, serverless and SaaS
The right pattern is usually control-plane first, resource-native second, and network enforcement only where it adds genuine value. That means using cluster-native identity and role mapping for Kubernetes, platform-native roles and short-lived credentials for serverless, and direct API or app-level integration for SaaS. The common thread is that the IAM layer should manage who can act, on which resource, for how long, and under what conditions.
In that model, cloud workload identities are preferred over static shared secrets, because they can be tied to the runtime, rotated automatically, and constrained to a narrower audience. The best-fit control is the one that the platform itself understands, not the one that only works when traffic happens to traverse a specific intermediary. The broader lifecycle and governance problem is why identity programmes need visibility, ownership and review discipline across all non-human access paths, not just human accounts: Identity Security Programme Guide.
Kubernetes and serverless usually reward short-lived, workload-bound credentials. SaaS usually rewards fine-grained app scopes, tenant-aware admin roles and strong provisioning and deprovisioning controls. When those are wired together properly, teams get better audit trails, tighter blast-radius control and fewer exceptions than they would from a generic network mediation layer.
Risk and Threat Considerations
The main risk is false coverage: teams believe a proxy or network control is governing all cloud access when, in reality, the most sensitive actions happen through APIs, service roles or tenant-native permissions that never rely on that proxy. That creates gaps in visibility, privilege control and incident response, especially when workloads, functions or SaaS integrations inherit long-lived credentials or broad service permissions.
Failure mechanism: A single mediation layer cannot uniformly enforce policy across dissimilar cloud control planes, so a caller may bypass the intended control path by using the platform’s native API, a direct service role or an application-specific token.
Impact: The result is uneven enforcement, missed revocation, overprivilege and a larger blast radius if a workload, secret or SaaS integration is compromised. The control may still log traffic, but it will not reliably constrain what the target system actually allows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Cloud workload and service-to-service trust require native non-human authentication. |
| AC-6 — Least Privilege | Cross-platform cloud access needs tight scope across cluster, function and SaaS permissions. | |
| IA-5 — Authenticator Management | Modern cloud access depends on short-lived credentials, tokens and secret lifecycle control. | |
| Recommendation — Use IA-9 to authenticate workloads and services directly instead of relying on network mediation. Apply AC-6 to right-size permissions for each cloud access path and service scope. Use IA-5 to manage issuance, rotation and revocation of credentials and tokens. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Cloud access spanning multiple platforms needs consistent access policy and enforcement. |
| A.8.5 — Secure authentication | Kubernetes, serverless and SaaS rely on platform-native authentication mechanisms. | |
| Recommendation — Implement A.5.15 to define and enforce access rules across cloud services. Apply A.8.5 to use secure, service-appropriate authentication methods for each platform. | ||
| OWASP ASVS | V8 — Authorization | SaaS and API-backed cloud operations depend on correct authorization at the application boundary. |
| Recommendation — Use V8 to verify that each cloud-facing app enforces resource-level authorization. | ||
| CSA Cloud Controls Matrix | IAM — IAM | Cloud control matrices explicitly cover identity and access across cloud services and workloads. |
| Recommendation — Use IAM controls to govern identities, entitlements and trust relationships across cloud platforms. | ||
Practitioner Guidance
What to prioritise: Classify each access path by the resource it governs, then decide whether Kubernetes, serverless or SaaS needs native control-plane enforcement, not just network mediation. If the platform exposes its own authorization model, use it.
What to verify: Confirm that every high-value workload, function and SaaS integration has a direct, reviewable trust relationship, a scoped credential or token, and an owner who can answer who can revoke it. If you cannot answer that quickly, the access path is not operationally mature.
Common mistake: Treating proxy coverage as evidence of authorization coverage. That shortcut usually fails first on service-to-service calls, then on SaaS admin scopes, then on ephemeral cloud workloads that never traverse the proxy at all.
Practitioner takeaway: Design for the cloud service’s native control plane first, because modern IAM succeeds when policy follows the resource and fails when it depends on a single path of traffic.
Related resources from NHI Mgmt Group
- How should teams secure non-human identities across cloud and SaaS?
- What should IAM teams do when access spans multiple SaaS sessions and federated apps?
- How should security teams decide whether JIT access is safe for non-human identities?
- What do teams get wrong about access review findings in cloud IAM?