Not so long ago, we released the Credentials Vault capability, which lets you centrally manage credentials used by Kentik NMS to poll your devices. This allowed for a much more efficient way to provision NMS devices in Kentik:

• without having to redefine the same credentials for each device
• supporting the need to swap the credentials used by Kentik for a large amount of devices in a central way

The Credentials Vault was released including Synthetic Monitoring capabilities to let users leverage centrally defined credentials from the Vault in the authentication steps of all forms of HTTP and Transaction Tests.

We are also currently extending the Credentials Vault-only method  from Kentik NMS to flow devices - as you know, both SNMP polling and BGP MD5 config info for these is still currently stored at a local, device-per-device level. This should feature should be released in the weeks to come, and once done, both NMS and Flow devices will both exclusively leverage the Credentials Vault.

Yet, this post focuses another aspect of Credentials Vault that we are improving today.

What is RBAC for Credentials Vault ?

When we created Credentials Vault, we relied on our legacy User Levels (Member, Admin, SuperAdmin) to go with simple defaults: basically Members cannot create any credentials but can list/use them, while only Admins and SuperAdmins are allowed to create/update/delete credentials - and this all seemed like reasonable defaults.

We have heard from a few Customers that their Synthetic Testing users were Member type users allowed to create and author Synthetic Tests, but were blocked because they weren't allowed to create credentials. The corollary being that these users would need to ask Admin users to register these secrets for them in their place, increasing the risk surface of leaking them when needing to send them over email or chat.

We agreed that this was not the most secure approach to it and took the opportunity to roll Credentials Vault into our RBAC framework.

How can you add RBAC permissions to users to let them create Credentials in the Vault?

Users with the ability to create and edit RBAC roles will now be able to assign these new permissions to roles (and in turn the users these roles are assigned to)

Beyond this, the label-based permission framework has been made available to Secrets in the Credentials Vault so that users can for instance only have access for view and edit to secrets with specific labels.

For instance, the following Vault Secret Creators role will allow users in this role to:

• to create secrets
• only view and use secrets labeled Production or CDN
• only update credentials with the CDN label

So to conclude, if you need your low-privilege Member users to be able to create credentials, a speedy option is to

1. create a new RBAC Role containing the "Can create credential secret" permission enabled
2. directly add users to that role from the "Users" tab of the same screen
3. profit.