Skip to content

Cannot add profile X: requires profiles get X

A DRP that advertises the profile-attach-rights feature refuses any write that adds a profile the caller cannot read. A task, a user or a script that adds a profile without profiles get on it fails with this error.

Problem

After an upgrade to that DRP, tasks that worked before fail as soon as they add a profile to a machine, cluster, resource broker, work order, user or other profile. There is no setting to turn the check off. Content and roles written for earlier releases must be updated.

Symptoms

A task's job log ends with an AUTH error that names the profile and the task:

Text Only
Error: AUTH: machines/9ce406e7-...: Cannot add profile universal-application-discover: requires profiles get universal-application-discover. Add it to the ExtraClaims of task classify
Task classify failed

The machine stops, not runnable, in the stage that ran the task.

A user or script calling the API, or drpcli, gets a 403:

JSON
{
  "Model": "machines",
  "Key": "9ce406e7-...",
  "Type": "AUTH",
  "Messages": ["Cannot add profile p1: requires profiles get p1"],
  "Code": 403
}

Pool operations (drpcli pools manage allocate, add, release or remove with --add-profiles, or a pool whose actions add profiles) report success for the pool, but return each refused machine with a failed status:

JSON
"Status": "FAILED: AUTH: machines/9ce406e7-...: Cannot add profile p1: requires profiles get p1"

A content pack updated for the check refuses to load on an older DRP:

Text Only
Content layer classify (v4.17.1) requires feature profile-attach-rights, but dr-provision (v4.17.5) does not provide it

Cause

Adding a profile to an object gives that profile's params, secure ones included, to anyone who can read the object. Before this check, a caller who could update an object could add any profile to it and then read the profile's secrets through the object. The check closes that: each profile a write adds needs profiles get on that profile, in the caller's tenant.

The rule applies to every caller, including the token a task runs with. A job token grants rights on its own machine but has no profiles claim, so a task that adds a profile must ask for it in its ExtraClaims.

These writes are not checked:

  • Profiles already on the object. Existing objects keep working, and removing a profile needs no rights on it.
  • A profile created earlier in the same request. A cluster or resource broker create attaches the profile it makes for itself this way.
  • Content pack loads and server-internal writes, such as triggers.

Resolution

RackN content

Upgrade these packs to the release that lists profile-attach-rights in RequiredFeatures. Each one adds the claims its tasks need, and installs only on a DRP that advertises the feature:

  • task-library: inventory-minimal, cluster-add-params, cluster-restart-pipeline, work-order-run, blueprint-to-cluster-members, terraform-apply, bootstrap-contexts
  • classify: classify, which also runs the universal discover, start and idle classifiers
  • eikon: eikon-mount-probe
  • openshift: openshift-manage-in-process-machines
  • openshift-cluster-ocpv: openshift-cluster-ocpv-deploy-broker
  • libvirt: libvirt-create-resource-broker
  • bios: bios-rack-decomm-execute
  • packet-ipmi: packet-console
  • image-deploy: id-test-init-test, id-test-next-test

Older versions of these packs fail on a DRP that checks. Upgrade DRP first, then the packs.

Your own tasks

The error names the task. Add a profiles claim with get to its ExtraClaims. Name the profiles when the task always adds the same ones:

YAML
ExtraClaims:
  - scope: "profiles"
    action: "get"
    specific: "my-app-base,my-app-tuning"

Use specific: "*" only when the profile names come from params or other data. That lets the task read every profile while it runs. Once the task claims the profile, add profile-attach-rights to your pack's RequiredFeatures, so the pack refuses to load on a release that does not check.

See ExtraClaims.

Users and roles

Give the user a role with profiles get on each profile they need to add. A role that grants profiles get * is not affected. A role narrower than that also needs profiles get global,rackn-license, which the portal reads to load its settings and license.

Separately, the same DRP lists only the objects the caller may get. A role that grants list without get on a scope now lists nothing there. The stock readonly and operator roles in the updated drp-community-content grant get,list on ux_views, plugin_providers and trigger_providers for this reason. Update roles copied from older versions the same way, or the portal loses the views its navigation uses. See Listing Needs Get.

Validation

Re-run the failed task, or restart the machine's workflow. It should pass the step that added the profile.

For a user, add the profile the same way the user did, logged in as that user:

Bash
drpcli machines addprofile <uuid> <profile>

The command succeeds once the role grants profiles get on the profile.

Additional Information

Additional resources and information related to this Knowledge Base article.

See Also

Versions

DRP v4.17 releases that advertise the profile-attach-rights feature, and later. To check an endpoint:

Bash
drpcli info get | jq '.features | index("profile-attach-rights") != null'

Keywords

profile, addprofile, extraclaims, claims, profiles get, 403, auth, cannot add profile, profile-attach-rights, requiredfeatures, job token, roles, list, get

Revision Information

Text Only
KB Article     :  kb-00090
initial release:  2026-09-30
updated release:  2026-09-30