Permissions Reference

ENTERPRISE

Understanding DC/OS access and permissions references

You can control DC/OS access by resource and operation. See Permissions Management for details on how to control permissions. This page provides a reference for each of the available DC/OS permissions.

Enforcement

DC/OS permissions are enforced based on your security mode.

Permissions

The available actions are create, read, update, delete, and full. By convention, full indicates that the permission supports all other action identifiers. The action full may include actions not supported by any other action identifier.

Many resource identifiers include optional sections in square brackets that may be filled in to further narrow the granted permission. If optional sections are omitted the resource identifier refers to all possible values. For example, the resource identifier dcos:mesos:agent:framework:role controls view access to DC/OS services registered with any Mesos role, whereas the resource identifier dcos:mesos:agent:framework:role:slave_public controls view access to DC/OS services registered with the role slave_public.

Most HTTP requests sent to DC/OS components require authentication proof. These include operations launched by the DC/OS CLI, the DC/OS UI, the DC/OS API and internally between DC/OS components. HTTP requests to some endpoints require additional authorization. Many DC/OS components are issued with DC/OS service account users and are individually granted necessary permissions when the cluster is first installed.

There are several components of DC/OS that perform authorization of requests, for example, Admin Router, Mesos, Marathon, and so forth. They are called authorizers in this context. All the authorizers follow the DC/OS authorization procedure. A high-level description of the DC/OS authorization procedure follows.

When a HTTP request to a protected resource is received by an authorizer, the authorizer inspects the Authorization HTTP request header to obtain the DC/OS authentication token. The DC/OS authentication token is validated and evaluated by the authorizer. After the uid is extracted from the DC/OS authentication token, the authorizer checks that the corresponding DC/OS user has been granted the necessary privilege to perform the requested operation. For example, the DC/OS user identified by uid must have full access to the protected resource dcos:adminrouter:package in order to be able to access the DC/OS package API through Admin Router.

Admin Router permissions

NOTE: Mesosphere does not currently support permissions inheritance for nested services in AdminRouter.

Most HTTP requests made to a DC/OS cluster pass through Admin Router. Admin Router performs authorization for some services. For example, the DC/OS user identified by uid must have full access to the protected resource dcos:adminrouter:package in order to be able to access the DC/OS package API through Admin Router.

Admin Router does not provide fine-grained actions. All permissions must use the full action.

Mesos permissions

Many Mesos operations require authorization. The necessary privileges must be assigned to the DC/OS user who issues the HTTP request to Mesos. This is not always the same DC/OS user who is logged into the UI or CLI. For example, when Alice uses the UI to create a Marathon application, Marathon performs authorization of the HTTP request and checks that the alice DC/OS user has create access to the dcos:service:marathon:marathon:services:/ resource. If so, it uses its own DC/OS user, a DC/OS service account with a uid of dcos_marathon, to authenticate an HTTP request to Mesos with instruction to launch the new Mesos tasks. At that point, Mesos will perform the DC/OS authorization procedure and check that the dcos_marathon DC/OS user has been granted the create action on the dcos:mesos:master:task:app_id resource.

Services launched with Marathon can only receive offers for resources reserved for the role as which the service is launched. See Quota Management for information on Marathon service role conventions and Mesos roles for information on roles.

Marathon and Metronome permissions

Marathon and Metronome require that HTTP requests made to certain protected resources must be authorized. For example, a DC/OS user must be granted the create action on the dcos:service:marathon:marathon:services:/dev resource in order to create a new Marathon app in the /dev service group.

Secret Store permissions

These permissions control access to the Secrets API. A Mesos framework must have permission granted to its DC/OS service account in order to access a given secret. If you are looking for information on how to launch Marathon applications using secrets see Configuring services and pods to use secrets.

Cluster Linker permissions

A DC/OS user requires permission to link clusters.

Superuser permissions

Similar to the Windows Administrator or Linux root accounts, DC/OS has the concept of the superuser. A user with at least one permission out of create, read, update, delete or full on the dcos:superuser resource has complete, unrestricted access to any operation throughout DC/OS. This is extremely powerful and this permission should be granted sparingly.