> ## Documentation Index
> Fetch the complete documentation index at: https://docs.macstadium.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How access works in Orka

> How Orka access fits together: Customer Portal sign-in, RBAC roles and groups, namespace access, service accounts, and how long each Orka credential lasts.

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](https://docs.macstadium.com/orka/orka-cluster-access/orka-cluster-access-the-cluster.md) 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.

| Portal role | Group in the token | Cluster access |
| - | - | - |
| Admin | `oidc:Administrator` | Full Orka administration, including namespaces, role bindings, service accounts, and nodes |
| Tech | `oidc:Technical` | Developer access: VMs, images, and VM configs in the namespaces they're granted |
| Billing | None that Orka binds | None. Billing users can sign in but can't run cluster operations. |

For the full list of what each role can do, see the access matrix in [Cluster access management overview](https://docs.macstadium.com/orka/orka-cluster-access/cluster-access-management-overview.md#role-based-access-matrix). For the roles and bindings behind it, and for clusters that use their own identity provider, see [Orka authentication, OIDC, and RBAC configuration](https://docs.macstadium.com/orka/orka-cluster-access/orka-authentication-and-rbac.md).

## 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`:

```bash theme={null}
orka rbac add-subject --role dev --namespace <NAMESPACE> --user <USER_EMAIL>
orka rbac add-subject --role dev --namespace <NAMESPACE> --serviceaccount <SA_NAMESPACE>:<SA_NAME>
```

`--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.

> [!NOTE]
>
> 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](https://docs.macstadium.com/orka/orka-cluster-access/orka-cluster-manage-access-to-resources.md) 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](https://docs.macstadium.com/orka/orka-cli-reference/namespace-management.md#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](https://docs.macstadium.com/orka/orka-cluster-access/orka-cluster-manage-service-accounts.md) 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.

| Credential | Use it for | How you get it | How long it lasts |
| - | - | - | - |
| Customer Portal credentials | Signing in to the Portal, `orka login`, and the Orka web UI | An invitation from your Portal admin | Until you change them in the Portal |
| User token | Running CLI commands as yourself | `orka login` | 60 minutes |
| Service account token | CI/CD pipelines and automation | `orka sa token` | 1 year by default. Set another lifetime with `--duration` (10 minutes or more), or use `--no-expiration`. |
| VM credentials | SSH and Screen Sharing into a VM | The macOS user account in the VM image | Until you change them in the image |

Orka might return a service account token with a shorter or longer lifetime than you request with `--duration`.

> [!WARNING]
>
> 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](https://docs.macstadium.com/orka/orka-cluster-access/understanding-orka-credentials.md).

## 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](https://docs.macstadium.com/orka/orka-cluster-access/customer-portal-manage-account-users.md). 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.

## Related pages

* [Cluster access management overview](https://docs.macstadium.com/orka/orka-cluster-access/cluster-access-management-overview.md)
* [Orka authentication, OIDC, and RBAC configuration](https://docs.macstadium.com/orka/orka-cluster-access/orka-authentication-and-rbac.md)
* [Understanding Orka credentials](https://docs.macstadium.com/orka/orka-cluster-access/understanding-orka-credentials.md)
* [Manage Orka service accounts for CI/CD](https://docs.macstadium.com/orka/orka-cluster-access/orka-cluster-manage-service-accounts.md)
* [Namespace management](https://docs.macstadium.com/orka/orka-cli-reference/namespace-management.md)


## Related topics

- [Understanding Orka Credentials](https://docs.macstadium.com/orka/orka-cluster-access/understanding-orka-credentials.md)
- [Cluster Access Management: Overview](https://docs.macstadium.com/orka/orka-cluster-access/cluster-access-management-overview.md)
- [Orka authentication, OIDC, and RBAC configuration](https://docs.macstadium.com/orka/orka-cluster-access/orka-authentication-and-rbac.md)
- [Manage Orka service accounts for CI/CD](https://docs.macstadium.com/orka/orka-cluster-access/orka-cluster-manage-service-accounts.md)
- [Orka on AWS architecture and deployment overview](https://docs.macstadium.com/orka/orka-on-aws-and-on-prem/orka-on-aws-getting-started.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.