Identity & Access Controls

The sign-in, MFA, role and token controls behind platform access - and the evidence each one produces for an audit.

Access control is where most security questionnaires start and where most audit findings land. This page is the compliance view of Ankra’s identity controls: what each control is, how to turn it on, and what evidence it produces. The step-by-step setup lives on the linked pages.

---

Sign-in and SSO

Ankra sign-in is handled by a managed identity provider rather than by password storage in the platform. Members authenticate there, and the platform receives the resulting identity.

Each sign-in is bound to the browser that started it. The platform sends the OpenID Connect state and nonce parameters and a PKCE challenge with every authorisation request - password, social, single sign-on and invitation sign-ins alike - and completes a sign-in only when the provider’s answer carries that state, the ID token carries that nonce, and the code is redeemed with the matching verifier. An answer the browser did not ask for is never completed: the sign-in restarts once, and a second unmatched answer stops on a page asking the person to sign in again. Connecting another sign-in method to an account is bound the same way, so a link started in one browser cannot be finished in another.

Single sign-on federates sign-in to your own identity provider, so accounts follow your joiner-mover-leaver process. An owner or admin connects an OpenID Connect provider - Microsoft Entra ID, Okta or any other - under Organisation → Settings → Single sign-on, with nothing for Ankra to enable first. The provider then decides who is a member and, if you map its groups, which role each member holds. Setup is in Single Sign-On.

The phrase “SSO-backed” appears throughout these docs in a second, narrower sense: Cluster Access and kubectl access mint short-lived Kubernetes credentials tied to the member’s Ankra identity, rather than distributing static kubeconfigs. That is true on every plan and is a different control from single sign-on federation.

Federating sign-in matters for two control families in particular: account provisioning and deprovisioning follows your directory, and your existing authentication policy - conditional access, device posture - applies to Ankra without Ankra needing to implement it.

Deprovisioning is not instant, and an auditor will ask how long it takes. Your provider does not notify Ankra of a removal; instead, a member the provider has not vouched for within the re-verification window is suspended, which stops their portal sessions, personal API tokens and Kubernetes access together. The window is 24 hours by default and can be set from 1 to 720 hours, so the answer to “how long does a leaver keep access” is at most one window. See How access ends.

---

Multi-factor authentication

Three second factors are supported, and an organisation can require MFA for every member.

Factor	Notes
Authenticator app (TOTP)	Six-digit codes from any authenticator app
Passkeys and security keys	WebAuthn, covering platform passkeys and roaming keys - phishing-resistant
Recovery codes	One-time use, issued at enrolment

When an organisation enforces MFA, a member who has not enrolled is blocked at sign-in until they do. That produces a clean binary answer to the “is MFA enforced for all users” question, and the state appears in the attestation section of the compliance report.

Setup and CLI equivalents are in Account Security & 2FA.

If your framework distinguishes phishing-resistant MFA - and increasingly they do - steer members to passkeys rather than TOTP. Both satisfy a generic MFA requirement; only WebAuthn satisfies a phishing-resistant one.

---

Roles and scopes

Ankra grants permissions through roles assigned at a scope: the whole organisation, a single cluster, or a cluster group. A role can also bundle the Kubernetes access provisioned on every cluster the scope resolves to, so platform permissions and kubectl access are granted and revoked together rather than drifting apart.

This is the structure that lets you answer least-privilege questions concretely:

• Scope narrowly. An engineer who operates one team’s clusters gets a role on that team’s cluster group, not on the organisation.
• Separate duties with custom roles. The audit.read permission can be granted on its own, so a compliance function reviews and exports the trail without administrative access. The same applies to security read.
• Use dynamic cluster groups. A group defined by a label selector keeps access correct as clusters are created and retired, instead of relying on someone remembering to update a static list.

Roles, scopes and the CLI commands for managing them are documented in Roles & Access.

---

Kubernetes access

Cluster access is granted through Ankra rather than by distributing credentials. Members authenticate as themselves and receive short-lived tokens minted on demand, so there are no static kubeconfigs to leak, rotate or collect on offboarding.

Requests reach the cluster through Ankra’s authenticated proxy, which is why this works for private clusters with no inbound network path. See Cluster Access and Accessing Clusters with kubectl.

An organisation access policy sets a ceiling on the role any grant can carry, what a cluster’s creator is given, how long access above view may last, and from which role a grant needs a reason. For incident access without standing privilege, use break-glass elevation: time-boxed, reasoned access a person or service account gives itself, announced on your notification channels and recorded in the audit log.

The identity your cluster sees

The Ankra agent re-issues every proxied request to the API server as the member, using Kubernetes impersonation. The API server, its RBAC and your admission policies see this identity:

Field	Value
Username	ankra:user:<ankra-user-id> - the member’s or service account’s Ankra user ID, never an email address
Group	system:authenticated, which Kubernetes adds to every impersonated identity
Group	ankra:users, on every request through Ankra
Group	ankra:org:<organisation-id>, the organisation the credential belongs to
Group	ankra:grant:<role>, one per role the member holds on that cluster through a live grant (view, edit, admin or cluster-admin), whatever the grant’s scope. A grant that has expired or been revoked no longer contributes its group

The ankra: groups carry no permissions. Ankra binds every grant to the username, never to a group, so the groups only add names your policies can match. Do not bind a Role or ClusterRole to one of them yourself: that would grant access outside Ankra’s access policy and its audit trail.

The groups are sent by agent version 2.1.1223 and later. An older agent impersonates the username alone, and so does an agent whose own service account may not impersonate groups (the agent’s chart grants that permission; the agent logs a warning when it is missing). Check what a cluster sees with your Ankra kubeconfig:

kubectl auth whoami

The Groups row lists the ankra: groups when they arrive.

Because the groups can be absent, write admission policies that use them to exempt a caller, never to deny one. This ValidatingAdmissionPolicy (Kubernetes 1.30 or newer) refuses namespace deletion through Ankra unless the member holds a cluster-admin grant on the cluster, such as a break-glass elevation. Requests that do not come through Ankra are left alone:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: ankra-namespace-delete-needs-cluster-admin
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["DELETE"]
        resources: ["namespaces"]
  matchConditions:
    - name: through-ankra
      expression: "request.userInfo.username.startsWith('ankra:user:')"
  validations:
    - expression: "'ankra:grant:cluster-admin' in request.userInfo.groups"
      message: "Deleting a namespace through Ankra needs a cluster-admin grant on this cluster."
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: ankra-namespace-delete-needs-cluster-admin
spec:
  policyName: ankra-namespace-delete-needs-cluster-admin
  validationActions: ["Deny"]

On an agent older than 2.1.1223 this policy refuses every namespace deletion through Ankra, including by holders of cluster-admin, which fails closed. A cluster-admin grant scoped to a single namespace also produces ankra:grant:cluster-admin; if the exemption should mean cluster-wide access only, issue cluster-admin at cluster scope.

Ankra service accounts reach the cluster through the same gateway as people, as ankra:user:<uuid> with the same groups, so this policy applies to automation too. A service account that deletes namespaces needs its own cluster-admin grant on that cluster, or a break-glass elevation to cluster-admin where the organisation access policy allows it.

The Ankra audit log records who was given Kubernetes access and every credential minted against a cluster: access grants and their changes, kube-token minting (which is also how a kubeconfig is generated), and every pod terminal session, with a recording of the session. Individual Kubernetes API calls - through Ankra’s proxy or any other client - are recorded only by your cluster’s own audit policy. If you need a trail of in-cluster API activity, enable Kubernetes audit logging on the cluster.

---

API tokens

Automation authenticates with API tokens rather than member credentials. For anything scheduled - evidence pulls, pipeline agents, integrations - issue a token for a member whose role grants only what the job needs, and treat the token as a credential with an owner and a review date.

See Tokens for issuing and revoking them.

---

Evidence map

Control	Where to get evidence
MFA enforced for all members	Attestation section of the compliance report
Who holds which role, at what scope	Role assignments under Organisation → Settings, and the audit export for changes
Access changes over a period	Audit export filtered to access actions
Joiner, mover, leaver activity	Invitation, assignment and revocation entries in the audit trail; with single sign-on, the sso_member_provisioned, sso_member_role_synced, sso_member_suspended and sso_member_restored entries
Single sign-on configuration and who changed it	The sso_connection_*, sso_policy_updated, sso_domain_* and sso_group_mappings_updated entries in the audit export
Privileged access review	Role assignments plus the agent’s cluster-admin binding, covered in Agent Compliance Posture
Credential handling	Where it lives for how stored credentials and SOPS keys are held

An access review usually needs two things: the current state, and the changes since the last review. The assignment views give you the first and the audit export gives you the second.

---

Related

Roles & Access

Define roles, scopes and cluster groups.

Account Security & 2FA

Enrol factors and enforce MFA.

Audit Export

Export access changes for review.

Cluster Access

Short-lived, identity-backed kubectl access.