Skip to main content
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. 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. 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.
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

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.

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.