Security overview
How Akasha authenticates users, isolates projects, and splits security responsibilities between the platform and your team.
Akasha is private by default: nothing you create is reachable from the internet until you deliberately expose it. This page summarizes how authentication, authorization, and tenant isolation work on the platform, and which parts of the stack you are responsible for securing.
Authentication
Sign-in to the web console goes through your organization's single sign-on (SSO) using OpenID Connect. There are no local usernames or passwords on the platform — Akasha never stores password credentials, and account lifecycle (creation, password resets, disabling) is handled by your administrator through the SSO provider.
API access uses the same identity: every request to the Akasha API carries an OIDC bearer token in the Authorization: Bearer <token> header. Tokens expire and must be refreshed through SSO; treat any token you hold as a credential with your full access. See Authentication for details.
The console and API endpoints are served over TLS.
Authorization
Permissions are project-scoped. A standard user is granted full access to one or more projects; administrators hold a separate superuser role. There is no way to escalate from a project grant to another project or to superuser — the roles are distinct.
Authorization is enforced server-side on every API request. The console hides actions you cannot perform, but that is a convenience: the API itself rejects any request that targets a project you have no grant for, including cross-project operations such as copying or migrating resources. Administrator-only actions — creating projects, setting project limits, managing users and permissions, mapping public IPs — are rejected for standard users regardless of what the request looks like.
Your grants come from group membership in your SSO provider. To view them, go to Access in the console; to change them, ask your administrator. See Access control.
Tenant isolation
Projects are the isolation unit for both networking and storage:
- Each network you create in a project is a separate layer-2 segment. There is no routing between projects: traffic from one project cannot reach another project's networks.
- Traffic from project networks to the platform's management infrastructure is blocked.
- Instances get private IPs only. Outbound internet access works through NAT egress, but nothing accepts inbound connections from the internet until you expose it — through a network forward, a load balancer, a Kubernetes External IP, or a public IP mapping configured by your administrator.
- Storage is project-scoped: volumes, buckets, and custom ISOs in your project are not visible to, and cannot be attached by, other projects.
Kubernetes clusters
The kubeconfig you download for a managed cluster carries cluster-admin access — anyone holding it has full control of that cluster. Treat it as a secret: store it in a credential manager, do not commit it to version control, and share it only with people who should administer the cluster. See Access clusters.
The cluster's API server endpoint is a virtual IP on your project's private network. It is not reachable from the internet unless you deliberately expose it.
Shared responsibility
| Akasha manages | You manage |
|---|---|
| Platform services, console, and API | Operating system updates inside your instances |
| Physical hosts and platform infrastructure | Your workloads and their dependencies |
| Talos Linux node OS on managed cluster nodes | What you expose (forwards, load balancers, External IPs) and who can reach it |
| Project isolation and server-side access control | Secrets and credentials: kubeconfigs, API tokens, S3 access keys |
| TLS on platform endpoints | Backups of your application data |
Note that on managed Kubernetes clusters the node operating system (Talos Linux) is maintained by the platform, but everything running inside the cluster — workloads, add-on configuration, exposed services — is yours to secure.
Recommendations
- Protect kubeconfigs and API tokens like passwords. Rotate anything that may have leaked and ask your administrator if you suspect a compromise.
- Expose services deliberately. Before you create a forward, load balancer, or External IP, know what will be reachable, and restrict traffic with network ACLs where appropriate.
- Scope S3 bucket access keys: use the Read-only role wherever write access is not needed. See Buckets.
- Take regular instance snapshots and volume snapshots, and schedule etcd backups for managed clusters.
- Keep the software inside your instances patched — the platform does not update your instance operating systems.