User Self-Access Roles¶

Users carry their own params and profiles, the same as machines. A common use is a user's own BMC credentials: when a user sets ipmi/username and ipmi/password, the remote BMC consoles log them in as themselves instead of with the machine's account.

What a user may do with their own params is set by roles, like everything else. This page shows a superuser how to give a user one of three levels:

Prerequisites¶

• DRP v4.18 or later, which advertises the user-params and authz-check features:

  Bash

  drpcli info get | jq '.features | map(select(. == "user-params" or . == "authz-check"))'
  

• A superuser login, or another role that can create roles and update users.

• The user already exists. See User.

How It Works¶

A claim names a fixed object in its Specific field. There is no value meaning "the caller", so a role that lets alice manage her own params must name alice. Each user who needs self-access gets a role of their own. This page names that role <user>-self.

Three claims on the users scope make up the levels:

update:/Params is a path-qualified update. It covers only the user's Params, so the user cannot attach profiles, change roles, or edit their description. See Role for how claims are matched.

Three further rules come from DRP itself, not from roles:

• A user's own secure params decrypt only for that user. Only alice gets the plaintext of a secure param stored on alice. Everyone else, superuser included, sees it sealed.
• Only a login counts. A token someone else minted for the user reads the user's secure params sealed, even with getSecure. The user has to log in themselves.
• getSecure on a user also covers the profiles attached to them. A user with getSecure on themselves can decrypt every secure param they inherit from their profiles, through the aggregated view, even when they cannot read those profiles directly. Before giving a user the Read level, check that no profile attached to them holds secrets they should not see.

The remote BMC consoles are different: DRP reads the credentials itself and hands them to the BMC, never back to the user. So a console uses a user's own ipmi/* credentials, whether stored on the user or on a profile they hold, whenever that user logged in themselves, with no getSecure needed. A user at the None level can still use BMC credentials an administrator set for them. On a token someone else minted for the user, a console is refused whenever the user has credentials of their own.

This is per-user credentials, not protection from DRP administrators. An administrator can still reach the value in other ways, for example by resetting the user's password and logging in as them.

Procedure¶

The examples use a user named alice. Replace it throughout.

Read¶

Create the role and add it to the user's existing roles:

drpcli roles create '{
  "Name": "alice-self",
  "Description": "alice can read her own secure params",
  "Claims": [
    {"Scope": "users", "Action": "getSecure", "Specific": "alice"}
  ]
}'
drpcli users show alice | jq -c .Roles
drpcli users update alice '{"Roles": ["console-bmc-operator", "alice-self"]}'

users update replaces the whole list, so include the roles the user already holds.

Read and write¶

Give the role all three actions, in one claim:

drpcli roles create '{
  "Name": "alice-self",
  "Description": "alice can read and manage her own params",
  "Claims": [
    {"Scope": "users", "Action": "getSecure,updateSecure,update:/Params", "Specific": "alice"}
  ]
}'

If alice-self already exists at the Read level, update it instead:

drpcli roles update alice-self '{
  "Claims": [
    {"Scope": "users", "Action": "getSecure,updateSecure,update:/Params", "Specific": "alice"}
  ]
}'

None¶

Remove alice-self from the user's roles. A role still held by a user cannot be destroyed, so remove it first if you want it gone:

drpcli users update alice '{"Roles": ["console-bmc-operator"]}'
drpcli roles destroy alice-self

Many users¶

A short loop creates a Read role for each user in a list:

for u in alice bob carol; do
  drpcli roles create "{
    \"Name\": \"$u-self\",
    \"Claims\": [{\"Scope\": \"users\", \"Action\": \"getSecure\", \"Specific\": \"$u\"}]
  }"
done

Add each role to its user as shown above.

Leave profiles to administrators¶

Do not give users update:/Profiles on themselves unless you trust them with every profile on the endpoint. A user who can attach profiles to themselves can attach one holding someone else's BMC credentials, and the remote console will then log them in with those. With getSecure on themselves, they can also decrypt every secure param on that profile.

Validation¶

Check each level as the user, not as a superuser:

export RS_ENDPOINT=https://drp.example.com:8092

# Read: decrypts
RS_KEY=alice:<password> drpcli users get alice param ipmi/password --decode

# Read and write: sets her own params; drpcli seals secure values
RS_KEY=alice:<password> drpcli users set alice param ipmi/username to '"alice"'
RS_KEY=alice:<password> drpcli users set alice param ipmi/password to '"<bmc password>"'

# Still refused: profiles and roles
RS_KEY=alice:<password> drpcli users addprofile alice some-profile

The last command fails with Requires: users update alice.

In the portal, open Users, then the user, then Params. A caller who cannot change a tab sees a "Read only" notice naming the claim that would allow it. A secure value the caller cannot read shows as sealed with the reason.

Troubleshooting¶

Requires: users getSecure <user>

The caller has no getSecure on that user. Add the Read level.

The value stays sealed for the user even with getSecure

The user is on a token someone else minted for them. They need to log in themselves.

The value stays sealed for a superuser

Expected. A user's own secure params decrypt only for that user.

Requires: users update <user> when adding a profile or changing roles

Expected at the Read and write level, which covers only Params.

The portal shows the tabs as editable but saves fail

The endpoint does not advertise authz-check, so the portal cannot ask what the caller may do and lets the server refuse. Upgrade the endpoint.

References¶

• Role
• User
• Authentication Operations