How to keep Kubernetes RBAC and audit logs consistent across STACKIT, IONOS and a hyperscaler

Key points:

• The three providers do not expose the same controls. STACKIT SKE signs users in through the STACKIT IdP and binds them with standard Kubernetes RBAC, but its kube-apiserver audit log forwarding is in Private Preview. IONOS Managed Kubernetes writes Kubernetes API audit logs to an Object Storage bucket you choose, but documents no OIDC sign-in for the Kubernetes API. EKS, GKE and AKS support an external or native IdP and ship audit logs to their own logging services.
• Use one identity provider and bind RBAC to groups. Federate Entra ID, Okta or Keycloak into each provider's sign-in path, then bind roles to groups, with a provider-specific subject name per cluster. Where the provider has no OIDC path for the Kubernetes API (IONOS today), put an authenticating proxy such as Pinniped in front.
• Keep RBAC as code in Git. One set of ClusterRoles and RoleBindings, applied with Argo CD or Flux, with a small overlay per provider for subject names. A policy engine (Kyverno or OPA Gatekeeper) rejects bindings that drift from the model.
• Ship every audit stream to one place and normalize it. SKE goes to a STACKIT Telemetry Router, IONOS to a bucket, EKS to CloudWatch Logs, GKE to Cloud Logging and AKS to a diagnostic setting. Normalize identity, timestamp, verb and object into one schema before you query.
• Qovery gives you one RBAC and one audit log for deployments across every cluster it manages, on STACKIT, IONOS or a hyperscaler, in your own accounts. It does not merge the Kubernetes API audit logs of those clusters; you still collect those yourself.

Running Kubernetes on STACKIT for sovereignty, IONOS for a public-sector contract and AWS, GCP or Azure for everything else is a common setup in Europe now. The clusters all run conformant Kubernetes. The access model and the audit trail around them do not match at all.

I work with platform teams who discover this during their first audit. Someone asks "who could change production last quarter, and who did?", and the answer is three IAM consoles, two kubeconfig formats and a bucket of JSON nobody has opened. This guide is the how-to I wish those teams had before the audit: what each provider gives you for RBAC, single sign-on and API-server audit logs (verified against their docs in November 2026), then the four building blocks that make them consistent. My colleague Romaric already compared what actually runs on STACKIT, IONOS and Open Telekom Cloud; this piece only covers access and audit.

What does each provider give you for RBAC, SSO and audit logs?

Every provider gives you standard Kubernetes RBAC inside the cluster, because RBAC is part of Kubernetes itself. They differ on three things around it: how a human gets a credential, whether that credential comes from your own identity provider, and whether the kube-apiserver audit log is available to you and where it lands.

Two gaps follow from that table. First, there is no single subject name for "the platform team" that works on all five. Second, two of the five do not give you a production-ready, documented path for one of the two problems: IONOS for SSO on the Kubernetes API, STACKIT for API-server audit logs.

How does STACKIT SKE handle access and audit logs?

STACKIT SKE gives you SSO and RBAC that behave like a hyperscaler's, and API-server audit logs that are still in preview. Access is solid today. Audit is the gap.

On access, the admin kubeconfig "does not contain secrets" and uses the STACKIT CLI to request short-lived credentials, for example with stackit ske kubeconfig create --expiration 60m. It "always grants full administrative permissions in the cluster" (STACKIT). Revoking admin kubeconfigs means rotating credentials, which also invalidates every other admin kubeconfig and Kubernetes ServiceAccount token. Keep admin kubeconfigs for break-glass use only.

For everyone else, STACKIT added identity-provider access in 2026: user and service accounts from the STACKIT IdP in April, then single sign-on and "fine-grained cluster permissions" with standard Kubernetes RBAC in June (STACKIT release notes). The behaviour is conservative, which I like:

• Users signed in through the STACKIT IdP only get the permissions of system:authenticated, which lets them query the Kubernetes version and resource types.
• Binding anything to system:authenticated is blocked once the integration is on, so nobody accidentally grants the whole organization access.
• The documented example binds a user by email: kubectl create rolebinding user-view --namespace default --clusterrole view --user [email protected] (STACKIT).

The STACKIT IdP itself federates with Microsoft Entra ID (through an Enterprise App), SAML 2.0 and generic OIDC providers (STACKIT IdP). So your corporate IdP stays the source of truth. The docs I read show per-user bindings and do not describe passing IdP group claims into Kubernetes RBAC, so test that before you design around groups. If groups do not come through, generate per-user RoleBindings from your IdP groups in Git (more on that below).

On audit, STACKIT has two different logs, and they get confused:

• The STACKIT Audit Log records calls to the SKE API: cluster creation, Kubernetes version updates, node pool changes, credential rotation and deletion (STACKIT FAQ). That covers who changed the cluster, but not who did what inside it.
• kube-apiserver audit logs can be forwarded to a STACKIT Telemetry Router, enabled with "audit": { "enabled": true } in the cluster payload or audit = { enabled = true } in Terraform. The feature page, last updated 1 October 2026, says it is "in Private Preview and available only upon request" and "not recommended for production use" (STACKIT).

STACKIT publishes the audit policy it uses. Secrets, ConfigMaps, token requests and token reviews are logged at Metadata only, reads (get, list, watch) at Request, writes to the built-in API groups at RequestResponse, and everything else at Metadata, with noisy system traffic such as leases and events dropped. That is a sensible default, and it tells you exactly what an auditor will and will not find. If your compliance scope needs API-server audit logs on SKE in production today, ask STACKIT about the preview timeline and write the gap into your risk register.

How does IONOS Managed Kubernetes handle access and audit logs?

IONOS Managed Kubernetes gives you the opposite profile: API-server audit logs you can turn on today, and no documented way to sign in to the Kubernetes API with your own identity provider.

On access, IONOS permissions live at the cloud level. A group privilege called "Create Kubernetes Clusters" lets contract users create, update and delete clusters, and each cluster's Security tab shares it with groups through Edit or Share checkboxes (IONOS). Users then download a kubeconfig, and only administrators can retrieve one before a node pool exists (IONOS). The FAQ describes "full cluster administrator level access to Kubernetes API" (IONOS FAQ).

IONOS supports IAM federation with OIDC or SAML, but the docs scope it to signing in to the Data Center Designer, not to the Kubernetes API server (IONOS). I could not find OIDC configuration for the Kubernetes API in the IONOS documentation. In practice, everyone with a downloaded kubeconfig looks like the same powerful identity to Kubernetes RBAC, unless you add a layer in front.

On audit, IONOS is ahead. You toggle "Audit logging" in the cluster settings and name an existing IONOS Object Storage bucket where the logs are stored (IONOS). The Terraform provider exposes the same thing as s3_buckets, described as a list that "for now" contains only "an IONOS Object Storage bucket used to store K8s API audit logs" (IONOS Terraform provider):

resource "ionoscloud_k8s_cluster" "prod" {
  name                  = "prod-de"
  api_subnet_allow_list = ["203.0.113.0/24"]
  s3_buckets {
    name = "prod-de-k8s-audit"
  }
}

What I could not find documented: which audit policy IONOS applies, the file format, and how often files are written. Enable it on a test cluster, read a day of files, and check whether the level of detail matches what your auditors expect before you rely on it. For actions on the IONOS Cloud API itself (logins, provisioning, configuration changes), IONOS has a separate, read-only Activity Log per contract (IONOS).

The weak spot with no OIDC path is attribution. If five engineers share an admin kubeconfig, the audit log in your bucket will faithfully record five people as one identity. The audit trail is only as good as the identity that reaches the API server, which is why the identity step comes first below.

What do EKS, GKE and AKS give you, and what trips people up?

The hyperscalers cover both halves, SSO and audit, but each uses its own subject names and logging service, and most of the audit logging is off by default.

• EKS lets you associate up to 10 OIDC identity providers on Kubernetes 1.32 or later (only one before 1.32), with a usernameClaim, groupsClaim and prefixes such as oidc: so that groups arrive as oidc:engineering (AWS). Control plane logs "aren't sent to CloudWatch Logs" by default; you enable the audit type yourself and pay CloudWatch ingestion and storage (AWS). IAM principals map to Kubernetes permissions through access entries.
• GKE recommends Workforce Identity Federation for external IdPs that speak OIDC or SAML 2.0. Identity Service for GKE is deprecated since 1 July 2026 and unsupported from GKE 1.37 (Google Cloud). Groups from a workforce pool appear in RBAC as principalSet://iam.googleapis.com/locations/global/workforcePools/...; Google Groups work through a parent group that must be named gke-security-groups (Google Cloud). Admin Activity audit logs are always on and cannot be disabled; Data Access logs are off by default (Google Cloud).
• AKS uses Microsoft Entra ID; you can disable local accounts so the shared admin credential stops working, and re-enable them for break-glass (Microsoft). kube-audit and kube-audit-admin are resource logs collected only once you create a diagnostic setting (Microsoft).

The formats differ too. EKS and AKS give you Kubernetes audit.k8s.io/v1 events. GKE wraps them as Cloud Audit Logs, with the audited data in a protoPayload field of a LogEntry (Google Cloud). Same events, different shape, so the central pipeline needs a parser per source.

How do I make access consistent with one identity provider?

Make one identity provider (Entra ID, Okta, Keycloak or Google Workspace) the source of truth for people and groups, connect it to each provider's sign-in path, and bind Kubernetes RBAC to groups. You cannot make the subject names identical across providers, so you make the mapping from IdP group to subject name explicit and keep it in one file.

Step by step:

1. Define a small role model in the IdP. For example: k8s-platform-admins, k8s-developers-<team>, k8s-readonly, k8s-breakglass. Four to six groups covers most organizations.
2. Connect the IdP to each provider. STACKIT: federate into the STACKIT IdP and enable the IdP integration on each SKE cluster. EKS: associate the IdP as an OIDC provider with a groups claim and an oidc: prefix. GKE: create a workforce pool. AKS: Entra ID integration, then disable local accounts.
3. Cover the provider without OIDC. For IONOS, deploy an authenticating proxy in the cluster. Pinniped is an open-source project built for this: it authenticates the user against your IdP and, when it cannot configure the API server, runs an impersonation proxy that "relays requests to the Kubernetes API server with the end user's identity". The API server then sees and logs the real user, and you keep the IONOS admin kubeconfig in a vault for break-glass only.
4. Write the mapping table down. One row per IdP group, one column per provider with the exact subject string. That table is what turns "consistent RBAC" from a promise into something you can diff.
5. Make admin credentials boring. Short expirations on SKE admin kubeconfigs, AKS local accounts disabled, the EKS cluster creator's admin access entry reviewed once your groups have access, IONOS kubeconfigs held by the platform team only. Every admin action outside the IdP path is a hole in the audit trail.

Upstream Kubernetes can do all of this natively through AuthenticationConfiguration, which accepts multiple JWT issuers with CEL claim mappings (Kubernetes). On a managed control plane you cannot pass API server flags or files, so you depend on what each provider exposes, and that is why the proxy step exists.

How do I keep RBAC itself identical across clusters?

Keep RBAC as code in one Git repository and apply it with a GitOps controller to every cluster. The ClusterRoles stay identical everywhere; only the subject names in the bindings change per provider, through a small overlay.

A layout that works:

rbac/
  base/                    # ClusterRoles, identical on every cluster
    platform-admin.yaml
    developer.yaml
    readonly.yaml
  overlays/
    stackit/   bindings.yaml   # subjects: user emails or STACKIT IdP identities
    ionos/     bindings.yaml   # subjects: identities issued through Pinniped
    eks/       bindings.yaml   # subjects: oidc:k8s-platform-admins
    gke/       bindings.yaml   # subjects: principalSet://...workforcePools/...
    aks/       bindings.yaml   # subjects: Entra group object IDs

Use Argo CD ApplicationSets with a cluster generator, or Flux Kustomizations per cluster, to apply base plus the right overlay. Three rules make this hold up in an audit:

• Write ClusterRoles yourself instead of binding cluster-admin, admin or edit broadly. Provider-managed defaults can change between versions and providers. Your own ClusterRoles stay the same.
• Only the GitOps controller writes RBAC objects. Nobody else gets create or bind on rolebindings and clusterrolebindings, so every RBAC change becomes a reviewed commit with an author and an approver.
• Generate per-user bindings when a provider cannot use groups. If SKE needs per-user bindings in your setup, a small script reads the IdP group and renders the overlay. The source of truth stays the IdP group.

Romaric covered sync policies and drift for this setup in more depth in GitOps at scale: consistent sync policies, RBAC and audit trails across multiple Kubernetes clusters.

How do I stop RBAC drift with a policy engine?

Install the same admission policies on every cluster so that a binding outside your model is rejected at the API server, whichever provider runs it. Kyverno and OPA Gatekeeper both work on STACKIT, IONOS and the hyperscalers because they only rely on standard admission webhooks.

Here is a Kyverno policy that only lets your platform admin group (and the built-in system:masters group) hold cluster-admin. Adjust the group name per overlay, and start in Audit mode for a week before you switch to Enforce:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-cluster-admin-bindings
spec:
  background: true
  rules:
    - name: only-platform-admins-get-cluster-admin
      match:
        any:
          - resources:
              kinds: ["ClusterRoleBinding"]
      preconditions:
        all:
          - key: "{{ request.object.roleRef.name }}"
            operator: Equals
            value: cluster-admin
      validate:
        failureAction: Audit
        message: "cluster-admin can only be bound to the platform admin group."
        deny:
          conditions:
            any:
              - key: "{{ request.object.subjects[?name != 'k8s-platform-admins' && name != 'system:masters'] | length(@) }}"
                operator: GreaterThan
                value: 0

Other policies worth having on every cluster: deny bindings to system:authenticated and system:unauthenticated (STACKIT already blocks the first one when its IdP integration is on), deny wildcards in custom Roles, and require an owner label on every RoleBinding. Kyverno also records violations in policy reports, which gives you some evidence on a cluster where API-server audit logs are not available yet.

How do I get one audit trail when every provider logs somewhere else?

Send every cluster's audit stream to one log store or SIEM, normalize the events into one schema, and keep the provider-level logs (STACKIT Audit Log, IONOS Activity Log, AWS CloudTrail, Google Cloud Audit Logs, Azure Activity Log) next to them. Kubernetes defines a log backend and a webhook backend for audit events (Kubernetes), but on managed control planes you only get whatever export the provider chose.

Then normalize. A minimal common record has: timestamp, cluster, provider, the authenticated user and groups, the impersonated user if any, the verb, the resource and namespace, the name, the response code and the source IP. Map every provider's username format back to the IdP identity using the table from the identity step, or your queries will treat oidc:[email protected] on EKS and [email protected] on SKE as two people.

For detection on top, Falco has a Kubernetes audit plugin, plus dedicated plugins that read audit events from EKS, GKE and AKS, so the same rules ("someone bound cluster-admin", "exec into a pod in production") run against all three hyperscalers.

Two things API-server audit logs will never tell you on their own. They record the credential, not the intent behind it, which gets worse when AI agents act on clusters (see per-agent attribution and audit trails). And they record what happened in one cluster, not the deployment that spanned five. That second gap is where a deployment-level audit log helps.

Which approach should I pick?

Pick all four building blocks in order of the gap they close. Identity first, because every audit log depends on it. Then RBAC as code, then policy, then the central audit pipeline. A platform layer sits above them for everything that is a deployment rather than a raw API call.

Where does Qovery fit in a STACKIT, IONOS and hyperscaler setup?

Qovery gives you one access model and one audit log for everything your teams deploy, across all the clusters it manages, whichever provider runs them. It does not replace or merge the Kubernetes API audit logs of those clusters.

Qovery is an Agentic DevOps platform. It deploys and runs applications, databases, jobs and Helm charts on Kubernetes clusters in your own cloud accounts. It can create and manage clusters on AWS, GCP, Azure and Scaleway, and it connects to clusters you already run: EKS, GKE and Scaleway Kapsule through the Qovery Operator, and any other conformant cluster, including STACKIT SKE and IONOS Managed Kubernetes, through the Qovery CLI (Qovery docs). The control plane is separate from your clusters, and your apps and data stay in your accounts.

For access and audit, that means:

• One RBAC model across clusters. Five built-in roles, plus custom roles scoped per cluster (read-only, create environment, full access) and per project (Qovery docs). A developer can deploy to the STACKIT staging cluster and only read the IONOS production one, set in one place. Custom roles are manageable as code with the qovery_custom_role Terraform resource.
• One identity provider. SAML or OIDC single sign-on with group synchronization, so a Qovery role follows the user's IdP groups (Qovery docs).
• One audit log for deployments. Every call to the Qovery API is recorded with timestamp, event type, target, change, user (or API token name) and tool (Console, Terraform provider, git push), with the post-change object attached (Qovery docs). A deployment to IONOS and a configuration change on EKS land in the same log, filterable by project, environment, service and user.
• Scoped tokens for automation and AI agents. API Policy Tokens use OPA policies to limit a token to exactly what it needs, such as deploying one environment (Qovery docs, background).

The practical effect is that fewer people need kubectl on production at all. When most changes go through Qovery, the per-provider API-server audit logs mostly show the Qovery agent and your break-glass accounts, and the "who deployed what, where" question gets answered in one place. Keep the identity, GitOps, policy and audit pipeline steps above for the access that remains. Qovery helps you meet access and change-tracking controls; it does not make you compliant on its own.

How do I set this up with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills and the MCP Server, then let your coding agent connect your existing clusters and review access. Every action needs your approval.

curl -fsSL https://skill.qovery.com/install.sh | bash

# MCP Server for Claude Code: OAuth, read-only by default
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

The first command installs the skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-terraform and others) into Claude Code, Cursor or another compatible agent. The second connects Claude Code to the Qovery MCP Server read-only, after an OAuth login you approve in the browser, so the agent can list clusters, environments and deployment status without changing anything. Then ask in plain language, for example: "with Qovery, connect my existing STACKIT and IONOS clusters next to my EKS cluster, and list which members can deploy to each one". Add write access only when you want the agent to change things:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

Start with the AI agent quickstart and the Claude Code integration.