Skip to main content
People sign in to an Orka cluster with their MacStadium Customer Portal account, and their Portal role decides what they can do in the cluster. Automation uses service accounts instead. This page explains how those pieces connect. Each section links to the page with the steps. This page describes Orka 4.0 and the orka CLI. On Orka 3.x clusters, the CLI is orka3, and the notes on this page call out where 3.x differs.

​
What happens when you run orka login?

orka login opens a browser window where you sign in with your Customer Portal credentials. Orka then saves a token for your Portal identity to your kubeconfig, on a context named orka. That token lasts 60 minutes. The CLI doesn’t renew it, so when it expires, run orka login again. orka login also switches your current kubeconfig context to orka. See Log in to your Orka cluster for the first time for the full first-time setup, including VPN access and your Orka API URL.

​
How does your Portal role become cluster permissions?

Your Portal role travels in your token as a group, and the cluster grants permissions to those groups. The following table shows how each Portal role maps to the cluster. For the full list of what each role can do, see the access matrix in Cluster access management overview. For the roles and bindings behind it, and for clusters that use their own identity provider, see Orka authentication, OIDC, and RBAC configuration.

​
Which namespaces can you reach?

It depends on the namespace:
  • orka-default: Admin and Tech users both have developer access. Admins also have administrative access.
  • A namespace you create: only admins have access at first. Orka adds role bindings for the new namespace, but only the admin group is in them.
To give a user or a service account developer access to a namespace, an admin adds them with orka rbac add-subject:
--role admin grants admin access across the cluster, so it doesn’t take --namespace. It works only through the admin bindings that exist when you run it. A namespace created afterward doesn’t include those subjects, so run the command again after you create namespaces.
In Orka 4.0, orka rolebinding add-subject (alias orka rb) still works but is deprecated. Use orka rbac add-subject --role dev. On Orka 3.x, use orka3 rolebinding add-subject.
See Manage namespace access to Orka cluster resources for the steps.

​
Which namespace does a command run in?

The first of these that’s set: the --namespace flag, the ORKA_DEFAULT_NAMESPACE environment variable, the namespace on the kubeconfig context named orka (not your current context), and then orka-default. orka login resets the namespace on the orka context to orka-default each time it runs, so use the environment variable for a default that lasts. Images, VM configs, and Android emulator configs always live in orka-default. See Which namespace a command uses for the commands this applies to and the exceptions.

​
How do service accounts fit in?

Service accounts are cluster-only identities for CI/CD pipelines and other automation. They don’t have a Portal account and don’t use orka login. Instead, you give the pipeline a service account token. When an admin creates a service account, Orka adds it to the developer role binding in its own namespace, so it can work there right away. To let it work in other namespaces, add it with orka rbac add-subject. Deleting a service account removes it from the developer role bindings. If you granted it admin access, also run orka rbac remove-subject --role admin --serviceaccount <NAMESPACE>:<NAME>. See Manage Orka service accounts for CI/CD for the steps.

​
Which credential should you use, and how long does it last?

Orka involves four kinds of credentials. The following table shows what each one is for and how long it lasts. Orka might return a service account token with a shorter or longer lifetime than you request with --duration.
Don’t use a user token in a pipeline. It expires after 60 minutes and breaks long-running jobs. Use a service account token.
For more on each credential, see Understanding Orka credentials.

​
How do you rotate or revoke access?

Each credential works differently:
  • A person’s access: change their role or disable them in the Customer Portal. See Customer Portal: Manage account users. Changes take effect at their next orka login. A token they already have keeps working with their old role for up to 60 minutes. To change which namespaces they can reach, update role bindings with orka rbac.
  • A service account token with an expiration: run orka sa token again to get a new token, and update your pipeline. Earlier tokens stay valid until they expire.
  • A non-expiring service account token: running orka sa token --no-expiration again returns the same token, so you can’t rotate it that way. To revoke it, delete the service account and create a new one.
  • VM credentials: change the password in your image, push the image, and redeploy VMs from it.