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. Enterprise SSO, which federates sign-in to your own identity provider so accounts follow your joiner-mover-leaver process, is available on the Enterprise plan. It is arranged with Ankra as part of onboarding rather than self-configured in the portal today.
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 enterprise SSO 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, session lifetime - applies to Ankra without Ankra needing to implement it.

​
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.
Actions taken against the Kubernetes API - through Ankra’s proxy or any other client - are recorded by your cluster’s own Kubernetes audit policy, not by the Ankra audit log. 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.