`dr enclave` - Enclave management

Register and operate enclaves — remote outpost clusters that run your DataRobot workloads on infrastructure you control. The dr enclave group wraps the Covalent Enclaves API, with one subcommand per operation. It is also available under the aliases enclaves, outpost, and outposts.

Synopsis

dr enclave <command> [flags]

Description

An enclave is a Kubernetes cluster registered with your DataRobot tenant that workloads can be scheduled onto. register returns the enclave's id together with its one-shot installation secrets; the installer materializes those as Kubernetes Secrets on the cluster, reports in, and the enclave activates on its own — there is no manual activate step.

deactivate takes an active enclave out of scheduling while keeping the record, and reactivate puts it back; delete removes it for good.

Two separate things govern who can do what:

Per-enclave access (dr enclave access) — the owner, user, and consumer roles on one enclave. Deploying a workload onto an enclave requires at least the user role.
Collection-level permissions (dr enclave permission) — who may create enclaves at all, and who may pin a workload to a chosen enclave, independent of any single one.

DataRobot system administrators bypass both and always have full access.

[!NOTE] The enclave command is currently behind a feature gate. Enable it by exporting DATAROBOT_CLI_FEATURE_ENCLAVE=true before running any dr enclave subcommand. See Feature gates for details.

The access and permission subcommands need ENCLAVE_RBAC_ENABLED on the server. Where it is off, grants and revokes are accepted as no-ops and every caller shows as fully permitted.

Quick start

export DATAROBOT_CLI_FEATURE_ENCLAVE=true

# Register an enclave and capture its one-shot installation secrets
dr enclave register --name my-enclave --output-format json > enclave.json

# Watch for it to come up on its own once the installer reports in
dr enclave list

# Let an entire organization deploy onto it
dr enclave access grant <enclave-id> --role user --org <org-id>

# Check what you can do with it
dr enclave access show <enclave-id>

Pin a workload to an enclave with dr workload create --enclave <name>.

Command groups

Command	Endpoint	Purpose
`dr enclave register`	`POST /api/v2/enclaves`	Register an enclave, returning install secrets.
`dr enclave get`	`GET /api/v2/enclaves/{id}`	Show a single enclave.
`dr enclave list`	`GET /api/v2/enclaves`	List the enclaves you can see.
`dr enclave deactivate`	`POST /api/v2/enclaves/{id}/deactivate`	Take an active enclave out of scheduling.
`dr enclave reactivate`	`POST /api/v2/enclaves/{id}/reactivate`	Return a deactivated enclave to service.
`dr enclave delete`	`DELETE /api/v2/enclaves/{id}`	Delete an enclave.
`dr enclave access grant`	`PATCH /api/v2/enclaves/{id}/sharedRoles`	Grant a role on one enclave.
`dr enclave access revoke`	`PATCH /api/v2/enclaves/{id}/sharedRoles`	Revoke a recipient's role on one enclave.
`dr enclave access list`	`GET /api/v2/enclaves/{id}/sharedRoles`	List who holds a role on one enclave.
`dr enclave access show`	`GET /api/v2/enclaves/{id}/permissions`	Show effective permissions on one enclave.
`dr enclave permission grant`	`PATCH /api/v2/enclaves/createAccess`	Allow a recipient to create enclaves.
`dr enclave permission grant --permission pin`	`PATCH /api/v2/enclaves/pinAccess`	Allow a user to pin workloads.
`dr enclave permission revoke`	`PATCH /api/v2/enclaves/createAccess`	Stop a recipient from creating enclaves.
`dr enclave permission revoke --permission pin`	`PATCH /api/v2/enclaves/pinAccess`	Stop a user from pinning workloads.
`dr enclave permission list`	`GET /api/v2/enclaves/createAccess`	List who may create enclaves.
`dr enclave permission list --permission pin`	`GET /api/v2/enclaves/pinAccess`	List who may pin, in your organization.
`dr enclave permission show`	`GET /api/v2/enclaves/permissions`	Show your own collection-level permissions.

All paths are served at the root of your DataRobot host. They are new: the API previously sat behind a /covalent prefix, and its access routes answered under /outposts. Those spellings still work server-side as deprecated aliases, but the CLI calls only the paths above, so dr enclave needs a DataRobot whose Covalent carries that change — it landed just after Covalent 11.12.0.

Subcommands

`register`

Register a new enclave with your tenant. The response carries the enclave id and status along with its one-shot installation secrets — they are shown only once and never persisted server-side, so capture them here. --output-format json writes them in a form you can feed to the installer; the default text output prints the equivalent kubectl create secret generic command for each one.

dr enclave register --name my-enclave
dr enclave register --name my-enclave --label team=research --label env=prod
dr enclave register --name my-enclave --output-format json

Flag	Description
`--name`	Name for the new enclave (required).
`--label`	Attach a `key=value` label. Repeatable.

Creating an enclave requires the collection-level create permission (see permission grant) or system administrator rights.

`get`

Show one enclave by id.

dr enclave get <enclave-id>

`list`

List the enclaves you can see. With RBAC enabled this is only those you hold a role on; system administrators see every enclave in the tenant.

dr enclave list
dr enclave list --output-format json

`deactivate`

Take an active enclave out of scheduling without deleting it. Only an ACTIVE enclave can be deactivated; anything else returns a conflict.

dr enclave deactivate <enclave-id>

`reactivate`

Return a deactivated enclave to service.

dr enclave reactivate <enclave-id>

`delete`

Delete an enclave. Prompts for confirmation unless --yes is given.

dr enclave delete <enclave-id>
dr enclave delete <enclave-id> --yes
dr enclave delete <enclave-id> --yes --output-format json

Flag	Description
`-y, --yes`	Skip the confirmation prompt.

Deleting an enclave that is already gone, and declining the prompt, are both no-ops that exit 0. --output-format json is how a script tells them apart from a real deletion:

{ "enclaveId": "<enclave-id>", "deleted": true }
{ "enclaveId": "<enclave-id>", "deleted": false, "reason": "not found" }
{ "enclaveId": "<enclave-id>", "deleted": false, "reason": "aborted" }

In JSON mode the confirmation prompt is written to stderr, so stdout carries nothing but the result document.

Access on one enclave

dr enclave access manages the roles held on a single enclave. Every subcommand names the enclave by id.

The three roles:

Role	Grants
`owner`	Full control, including sharing the enclave with others.
`user`	View and deploy onto the enclave.
`consumer`	View only — not enough to deploy.

A recipient is exactly one of --user (by username), --user-id, --group, or --org.

`access grant`

dr enclave access grant <enclave-id> --role user --org <org-id>
dr enclave access grant <enclave-id> --role consumer --user alice@corp.io
dr enclave access grant <enclave-id> --role owner --user-id <datarobot-user-id>

Flag	Description
`--role`	`owner`, `user`, or `consumer` (required).
`--user`	Grant a user by username.
`--user-id`	Grant a user by DataRobot user id.
`--group`	Grant a group by id.
`--org`	Grant an entire organization by id.

`access revoke`

Remove a recipient's role. Takes the same recipient flags as grant.

dr enclave access revoke <enclave-id> --org <org-id>

`access list`

List the recipients holding a role on the enclave, and which role each holds.

dr enclave access list <enclave-id>

`access show`

Show the effective permissions on the enclave — what the subject can actually do, after roles, organization membership, and any administrator bypass are resolved. Defaults to you; pass --user-id to inspect somebody else (system administrators only).

dr enclave access show <enclave-id>
dr enclave access show <enclave-id> --user-id <datarobot-user-id>

Permissions to create enclaves and to pin workloads

dr enclave permission governs two capabilities that target no single enclave, so these commands take no enclave id:

create: register new enclaves. Recipients are named by id: --user-id, --group, or --org.
pin: pin a workload to one chosen enclave with dr workload create --enclave, overriding the scheduler. Granted to users (--user-id) and groups (--group), not organizations. A group grant lets every member pin. The enclave must still be linked to the workload's use case, and the user still needs deploy access to it.

The two are independent: holding create does not allow pinning, and holding pin does not allow creating. A system administrator may create without a grant but needs a pin grant to pin.

Who may grant, revoke and list:

Permission	System administrator	Org admin	Anyone else
`create`	yes	no	no
`pin`	yes, any user or group in any organization	yes, users and groups in their own organization only (another organization's recipient: 403)	no (403), including users who hold `pin`

`permission grant`

dr enclave permission grant --permission create --org <org-id>
dr enclave permission grant --permission create --user-id <datarobot-user-id>
dr enclave permission grant --permission pin --user-id <datarobot-user-id>   # sys admin, or an org admin for a user in their org
dr enclave permission grant --permission pin --group <group-id>              # every member of the group may pin

A server that still grants pin to users only refuses --group with a 422; the CLI says the server needs to be upgraded. Revoking a group's grant doesn't affect a member who also holds a grant of their own.

Flag	Description
`--permission`	Permission to grant: `create` or `pin` (required).
`--user-id`	Grant a user by DataRobot user id.
`--group`	Grant a group by id.
`--org`	Grant an entire organization by id.

`permission revoke`

dr enclave permission revoke --permission create --org <org-id>
dr enclave permission revoke --permission pin --user-id <datarobot-user-id>
dr enclave permission revoke --permission pin --group <group-id>

`permission list`

List the recipients who have been granted the create permission, or with --permission pin the users and groups in your organization that hold pin. An empty result means nobody holds it; system administrators do not appear in the create list, because they bypass that permission rather than holding it.

dr enclave permission list
dr enclave permission list --permission pin

`permission show`

Show whether a subject may create enclaves or pin workloads, and where that comes from. Defaults to you; --user-id inspects somebody else (system administrators only).

dr enclave permission show
dr enclave permission show --user-id <datarobot-user-id>

Output formats

Every subcommand accepts --output-format (text or json). text is the default and is meant for reading; json is the one to use in scripts, and the only practical way to capture register's installation secrets.

dr enclave - Enclave management

Synopsis

Description

Quick start

Command groups

Subcommands

register

get

list

deactivate

reactivate

delete

Access on one enclave

access grant

access revoke

access list

access show