Default policy does not allow secrets to be deleted by non-admin creator

[Michael Durrant]

Currently - "secret:delete": "rule:admin and rule:secret_project_match"
What I believe it should be - "secret:delete": "rule:admin_or_creator_role and rule:secret_project_match"

Please let me know if this was intentional or if I'm missing something.

Thanks,
Michael

[Dave McCowan (dave-mccowan)]

This is absolutely intentional. Secrets are precious. They could be a decryption key for terabytes of irreplaceable data. To prevent the chance for accidental loss, the default policy for delete is admin only.

[Douglas Mendizábal (dougmendizabal)]

Default policy defines 4 roles, each with different permissions. The "admin" role is allowed to get metadata, decrypt the secret, upload new secrets, and delete secrets. The "creator" role allows for all those same actions except for delete.

There are use cases where you may want a user to be able to upload a secret, but not be able to delete it. One that comes to mind is for an automation system that creates keys (or passwords, etc) that is allowed to push those secrets to Barbican. Deletions should not be allowed by that same user, since we wouldn't want a bug in t automation system to run amok and delete a bunch of secrets.

In order to allow for such a use case, the "creator" role is necessary. Note that a project can have an arbitrary number of admins, so if you need to allow someone to delete secrets, they should be granted the admin role on the project.