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.

Permission Category Permissive Strict
Admin Router permissions (dcos:adminrouter) x x
Mesos permissions (dcos:mesos) x
Marathon and Metronome permissions (dcos:service) x x
Secret store permissions (dcos:secrets) x x
Cluster linker permissions (dcos:cluster:linker) x x
Superuser permissions (dcos:superuser) x x

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.

Resource identifier
dcos:adminrouter:acs
Controls access to the Identity and Access Management API.
dcos:adminrouter:ops:ca:ro
Controls access to the read-only endpoints of the Certificate Authority API and the dcos security cluster ca commands of the Enterprise DC/OS CLI.
dcos:adminrouter:ops:ca:rw
Controls access to signing endpoints of the Certificate Authority API and the dcos security cluster ca commands of the Enterprise DC/OS CLI.
dcos:adminrouter:ops:cockroachdb
Controls access to the CockroachDB UI at https://<master>/cockroachdb/.
dcos:adminrouter:ops:exhibitor
Controls access to the Exhibitor UI at https://<master>/exhibitor/ and API. This permission allows users to remove the ZooKeeper state after uninstalling a service.
dcos:adminrouter:ops:mesos-dns
Controls access to the Mesos DNS API.
dcos:adminrouter:ops:mesos
Controls access to the Mesos master UI at https://<master>/mesos/ and API.
dcos:adminrouter:ops:metadata
Controls access to the Metadata endpoint.
dcos:adminrouter:ops:networking
Controls access to the Networking and Network Metrics endpoints.
dcos:adminrouter:ops:slave
Controls access to the Mesos agent UI and API.
dcos:adminrouter:ops:system-health
Controls access to the System health API.
dcos:adminrouter:ops:system-logs
Controls access to System logs API.
dcos:adminrouter:ops:system-metrics
Controls access to System metrics API.
dcos:adminrouter:licensing
Controls access to the Licensing API.
dcos:adminrouter:package
Controls access to the Cosmos API, which provides access to the DC/OS Catalog.
dcos:adminrouter:service:<service-endpoint>
Controls access to the UI and API of an installed DC/OS service. See the Service Endpoint documentation for possible values of <service-endpoint> .
dcos:adminrouter:service:marathon
Controls access to the native Marathon instance.
dcos:adminrouter:service:metronome
Controls access to DC/OS Jobs (Metronome).

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.

Resource identifier full C R U D
dcos:mesos:agent:container:app_id[:<service-or-job-group>]
Controls access to the debugging features for a specific service or job.
x
dcos:mesos:agent:container:role[:<role-name>]
Controls access to the debugging features for the given Mesos role.
x
dcos:mesos:agent:endpoint:path[:<endpoint>]
Controls access to unprotected Mesos endpoints.
x
dcos:mesos:agent:executor:app_id[:<service-or-job-group>]
Controls view access to service and job executor information.
x
dcos:mesos:agent:flags
Controls view access to agent flag configurations.
x
dcos:mesos:agent:framework:role[:<role-name>]
Controls view access to DC/OS services registered with the given Mesos role.
x
dcos:mesos:agent:log
Controls access to the agent logs.
x
dcos:mesos:agent:nested_container_session:app_id[:<service-or-job-group>]
Controls access, by service or job group, to launching a container within a container of a service or job while debugging.
x
dcos:mesos:agent:nested_container_session:role[:<role-name>]
Controls access, by Mesos role, to launching a container within a container of a service or job while debugging.
x
dcos:mesos:agent:nested_container_session:user[:<linux-user-name>]
Controls access, by Linux user, to launching a container within a container of a service or job while debugging. The users of both nested containers must be the same.
x
dcos:mesos:agent:resource_provider
Controls view access to per-agent resource provider information.
x
dcos:mesos:agent:resource_provider_config
Controls access to changes of per-agent resource provider configurations.
x x x
dcos:mesos:agent:sandbox:app_id[:<service-or-job-group>]
Controls access to the Mesos sandbox.
x
dcos:mesos:agent:task:app_id[:<service-or-job-group>]
Controls access to task information.
x
dcos:mesos:master:agent
Controls access to deactivate/reactivate agent nodes (Update), and to drain agent nodes (Delete).
x x
dcos:mesos:master:block_disk
Controls access to create and destroy block disks.
x x
dcos:mesos:master:endpoint:path[:<path>]
Controls access to these unprotected Mesos endpoints: logging/toggle, /metrics/snapshot, and /files/debug.
x
dcos:mesos:master:executor:app_id[:<service-or-job-group>]
Controls access to executor service and job groups.
x
dcos:mesos:master:flags
Controls view access to master flag configurations.
x
dcos:mesos:master:framework:principal[:<service-account-id>]
Controls access, by service account ID, to the Mesos tear down endpoint, which allows you to uninstall a DC/OS service.
x
dcos:mesos:master:framework:role[:<role-name>]
Controls access, by Mesos role, to register as a framework with Mesos.
x
dcos:mesos:master:log
Controls access to the Mesos master logs.
x
dcos:mesos:master:mount_disk
Controls access to create and destroy mount disks.
x x
dcos:mesos:master:quota:role[:<role-name>]
Controls access, by Mesos role, to the resource quota.
x x
dcos:mesos:master:reservation:principal[:<service-account-id>]
Controls access, by user or service account, to unreserve resources.
x
dcos:mesos:master:reservation:role[:<role-name>]
Controls access, by Mesos role, to reserve resources.
x
dcos:mesos:master:task:app_id[:<service-or-job-group>]
Controls access to run tasks.
x
dcos:mesos:master:task:user[:<linux-user-name>]
Controls access to run tasks as a specific Linux user.
x
dcos:mesos:master:volume:principal[:<service-account-id>]
Controls access to destroy a volume.
x
dcos:mesos:master:volume:role[:<role-name>]
Controls access to create a volume for the given Mesos role.
x
dcos:mesos:master:weight:role[:<role-name>]
Control access to the weight for the given Mesos role.
x x

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.

Resource identifier full C R U D
dcos:service:marathon:marathon:admin:config
Controls access to the GET /v2/info Marathon endpoint.
x
dcos:service:marathon:marathon:admin:events
Controls view access to the Marathon events endpoint GET /v2/events.
x x
dcos:service:marathon:marathon:admin:leader
Controls access to the GET/DELETE /v2/leader endpoint.
x x x
dcos:service:marathon:marathon:services:/[<service-group>]
Controls access to DC/OS services launched by the native Marathon instance.
POST /v2/group requires the full action.
x x x x x
dcos:service:metronome:metronome:jobs[:<job-group>]
Controls access to jobs and job groups.
x x x x x

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.

Resource identifier full C R U D
dcos:secrets:default:[/<path-name>/]<secret-name>
Controls access to individual secrets.
x x x x x
dcos:secrets:list:default:/[<path>]
Controls view access to the names of secrets.
x

Cluster Linker permissions

A DC/OS user requires permission to link clusters.

Resource identifier full C R U D
dcos:cluster:linker:<cluster-id>
Controls access to individual cluster links.
x
dcos:cluster:linker:*
Controls access to cluster links.
x x x x

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.

Resource identifier full C R U D
dcos:superuser
Controls complete access to the DC/OS cluster.
x x x x x