RBAC

[v0lkan]

a workload shall be able to read secret of another workload; a workload shall be able to write secret of another workload; a workload; these actions shall be through VSecM Sentinel’s REST server; VsecM sentinel shall have several modes of operation (oidc/svid-authentication/etc); SDK will need updates to enable these too; those “policies” (for the lack of a different term) will be stored as a special secret linked to VSecM Sentinel; when VSecM Sentinel is not there, or when the VSecM sentinel server is disabled, or when the policy does not allow it the functioality will not work; also allow wildcard access (ability to write to all workloads; ability tyo read from all workloads)

---

Here’s a rough structure in my mind.

To manage RBAC, both Sentinel, and Safe will have special secrets.

Access will be denied by default, and you’ll need explicit rules to allow access.

Allowing access also means “I trust this workload with this spiffeid to take action on behalf of this other workload with this other spiffe id” – when that’s done, it’s up to the user to secure the workloads that have privileged access because any breach to them will give an attacker additional powers that they won’t have had otherwise.

The users will be advised to have a second layer of security (session-based authentication, OIDC, SSO, MultiFactor Authentication, etc) to use this feature, and these will be clearly explained in the docs; as in “don’t use this feature if you don’t know what you are doing”.

[v0lkan]

I also thought about doing this with OPA, but that would have meant if the OPA server is breached so will the system.

It’s better to keep the configuration guarded with the same principles VSecM guards its secrets.

That’s why the configuration will be set up as secrets bound to VSecM components: Sentinel and Safe will have their own secrets to identify access configurations.

[v0lkan]

Also note: Any privileged requests should go directly through VSecM Sentinel’s server first.

This way,

• Things will be audited at a central location
• VSecM sentinel can be deleted/locked as a first line of defense when the rest of the system still works.

[v0lkan]

This change will also require documentation update as in “by default only a workload can read its own secrets and no one else’s. If you want a workload to read the secrets assigned to another workload, you’ll need to define RBAC for it” etc.