Skip to main content
Ankra controls access with roles that you assign at a scope. A role is a set of permissions; a scope decides where those permissions apply - the whole organisation, a single cluster, or a cluster group. A role can also bundle Kubernetes access that Ankra provisions on every cluster in scope, so platform permissions and kubectl access are granted together.
Roles and scoped assignments replace the earlier admin/member split. Existing members keep working: admin and member map onto the new model, and wider roles become available as you adopt them.

​
How access is decided

An assignment ties a member to a role at a scope. When the role includes Kubernetes access, Ankra reconciles the matching Cluster Access grants onto every cluster the scope resolves to, and keeps them in sync as group membership changes.

​
Built-in roles

read-only from the earlier model maps to viewer. You can also define custom roles that bundle a specific permission set and, optionally, a Kubernetes access level provisioned across the assignment’s scope.

​
Permission matrix

Every permission Ankra checks, and which built-in role holds it. A custom role can hold any combination of these. The table is generated from the platform’s permission registry, so it lists exactly what the platform enforces. Two patterns to notice when you review access:
  • Every built-in role can read. All read permissions, including ask-mode AI (ai.use), are shared by every role. The exception is audit.read: only admin and owner hold it, and a custom role can grant it on its own.
  • Some powers sit only with admin and owner. Among them are revealing stored credentials (credentials.reveal), approving promotions (promotions.approve), managing members and tokens, and choosing the AI provider (ai.manage).
  • Reading a Kubernetes Secret’s values is its own permission. kubernetes.read shows a Secret’s key names and a digest of each value. The digest changes when the value changes, and it is keyed per cluster, so it cannot be used to check a guessed value. The values need kubernetes.secrets_reveal (in the console, Reveal values; in the CLI, ankra cluster get secrets <name> -n <namespace> --reveal), which operator, admin and owner hold and member and viewer do not, and every reveal is written to the audit log. Custom roles that already held kubernetes.write when the permission was introduced on 2026-10-01 were given it too, because a role that can apply workloads can already mount a Secret into one. Other custom roles, and API tokens restricted to a list of scopes, get it only when you add it. The same permission is needed to reveal the passwords and keys in a Helm release’s values, and to read or change Secrets with kubectl through Ankra, whatever role the access grant gives.
Human-only permissions reach an API or MCP token only when the token names them explicitly. A token that asks for “everything its owner can do” does not get them, so an automated caller cannot approve its own promotion or its own AI action.

​
Organisation, people and audit

​
Clusters and Kubernetes

​
Stacks, configuration and secrets

​
Applications and delivery

​
Alerts, security and backups

​
AI

​
Scopes

Assign the narrowest scope that fits. A support engineer who only triages one team’s clusters gets a viewer (or operator) role on that team’s cluster group, not the whole organisation.

​
Cluster groups

A cluster group is a named set of clusters used as an assignment scope. Groups can be:
  • Static - you pin specific clusters as members.
  • Dynamic - a label selector evaluated against cluster labels, so clusters join and leave the group automatically as their labels change.
Manage groups on the Roles page of your organisation (Organisation → Roles, section Cluster Groups). A preview shows exactly which clusters a group currently resolves to before you use it in an assignment.

​
Matching on a cluster’s environment

In a dynamic group, the environment key matches the Environment set on each cluster - on the cluster’s Overview page, or with --environment when you create it. The match is exact and case-sensitive, so production does not match a cluster set to Production, and a cluster with no environment never matches. Change a cluster’s environment and it moves in or out of every group on that key straight away, together with the Kubernetes access those assignments bundle. Every other key matches the cluster’s labels. Labels cannot be set from the console or the CLI yet, so build environment-based access on the environment key.

​
Example: restrict production to a DevOps role

Give a DevOps team full control of production, including Secret values, and everyone else read-only access with no actions.
1

Mark the production clusters

Set Environment to production on each production cluster’s Overview page.
2

Create a production group

Under Organisation → Roles → Cluster Groups, create a dynamic group with the selector environment = production. Check that the preview lists exactly your production clusters.
3

Create the DevOps role

Create a custom role holding the permissions the team needs - for full control, kubernetes.read, kubernetes.write, kubernetes.exec, kubernetes.secrets_reveal and clusters.operate - and give it the admin Kubernetes access level so kubectl works too. The built-in operator role holds the same platform permissions but bundles no kubectl access.
4

Assign it to the production group

Assign the DevOps role to each team member with the production group as the scope.
5

Give everyone else viewer

Assign viewer at organisation scope. Viewers read resources across every cluster but cannot apply, delete, restart, scale, open a terminal or reveal Secret values.
Assignments only add permissions. A role assigned at organisation scope also reaches production, so do not give anyone outside the DevOps team a writing role at organisation scope. Scope it to a non-production group instead, such as a dynamic group on environment = staging.
viewer still reads pod logs, ConfigMaps and environment values written directly into a pod spec, because kubernetes.read covers them. Only Secret values need kubernetes.secrets_reveal, so keep credentials in Secrets.

​
Assigning a role

1

Open Roles & Access

Go to Organisation → Roles. The same page holds Cluster Groups if you need a group scope. It is shown to members who can manage members (admin and owner by default).
2

Pick a member and role

Choose an organisation member, then a built-in or custom role.
3

Choose the scope

Assign at the organisation, a single cluster, or a cluster group.
4

Save

Ankra applies the assignment immediately. If the role bundles Kubernetes access, it reconciles the grants onto every cluster in scope.
To list the built-in and custom roles from the CLI:
The CLI has no commands for assignments or cluster groups; manage them on the Roles page.

​
Audit log

Every access change - invitations, role assignments, cluster-group edits, revocations - is recorded in the organisation Audit log under Organisation → Audit log, so you can see who changed what and when.

Cluster Access

Scoped, SSO-backed kubectl access.

Organisations

Invite and manage members.

Organisation Settings

Configure organisation-wide behaviour.

API Tokens

Create tokens for scripts, CI, and MCP clients.