Scopes

Octelium scopes are very similar to OAuth2 scopes. They act as a simple self-imposed authorization mechanism that can be used to further limit the scope of permissions that are already granted by the Cluster via its Policies (read more here). It is extremely important to understand that scopes are not a zero trust access control mechanism: they are voluntarily chosen by the Users themselves during the authentication process, not mandated by the Cluster's Policies. That said, once set, they are enforced by the Cluster on every request, which can meaningfully shrink the attack surface and prevent unauthorized access in case of a Session access token compromise.

Scopes are entirely optional. Users are not required to use them, and Cluster administrators must never treat scopes as a substitute for Policies.

You can choose to apply one or more scopes. Every scope is simply a string that represents a resource permission. Once your scopes are set for a Session during the authentication process, your Session cannot access anything outside the permissions granted by its scopes even if allowed by the Cluster Policies. There are currently 2 types of scopes: Service scopes and API scopes.

Service Scopes

Service scopes enable you to restrict access to certain Services or Namespaces of Services.

An individual Service has the scope service:<SERVICE>.<NAMESPACE> or directly service:<SERVICE> if it belongs to the default Namespace.

An entire Namespace of Services has the scope service:<NAMESPACE>/*. Here is an example of adding the Namespace ns1:

API Scopes

The Cluster API scopes enable you to restrict access to certain APIs. For example, you might want to only access the Core API:

You can also choose certain methods in a certain API. For example, you might only want to use the CreateUser method in the Core API:

Finally, you can also have multiple scopes by using the --scope flag multiple times. Here is an example: