Close the loop: less privileged keys

[grahamc]

Right now, Packet has a very limited set of ACL options for keys.

• A given key is read-only, or read-write
• A key can be for a user, with access to all of the organizations the user can, or for a project with access to only one project.

A read-write API key can make new read-write API keys.

As it is, this secrets engine is already valuable by making my secrets dynamic, and I can easily identify keys which shouldn't exist.

To fully close the loop and make this engine really good:

1. Packet's API should support creating API keys which cannot create new API keys
2. This Secrets Engine should make it possible, possibly even default, to hand out temporary tokens which don't have the authority to create API keys.

Maybe this could look like the Packet API accepting a basic "policy document" which I can provide to the secret engine. To start with:

{ "can_create_api_keys": false }

[t0mk]

I second this. If there's an API support, I will implement it in the secrets plugin.

[vielmetti]

This question has been relayed to the Packet API engineering team for review. Thanks for the detailed use case - I'll update as I have news.

[grahamc]

Here is a slightly more specific example of my workflow:

Graham logs in to the portal
├── Creates a 'read-write' API token which is allowed to create read-only and read-write API tokens
└── Graham enters that API token in to Vault
    └── Script requests a read or read-write key from Vault
        └── Vault creates an API key with read or read-write permission, which does NOT have permission to create API keys

[vielmetti]

Reviewing this again as a part of our audit of Packet integrations.

[grahamc]

🙏 🙏 🙏