Machine ID to use resources

[scottpgallagher]

What would you like Teleport to do? With Machine ID when we create a new bot we assign it a role or multiple roles it can assume. Now that we have the ability to leverage resources would like to be able to cut down on how much Machine ID has access to.

For example have Machine ID only be able to communicate to a single linux host as opposed to all the hosts that could be under a given role.

What problem does this solve? Cuts down on the attack vector of using Machine ID.

If a workaround exists, please include it. Only thing that comes to mind is a role that defines a label that is unique for a single given system.

[strideynet]

Thanks for raising this suggestion @scottpgallagher.

I see two routes this could be implemented:

• The resource restriction is applied to the bot itself, it can only generate certificates that can access those resources specified when creating the bot
• The resource restriction is configured by a user on a destination in tbot, and the certificates output to that destination are then restricted. As these certificates are the ones that are more likely to be vulnerable, I can see this making sense. I might have two applications running on a system, and I could grant resource specific access to each one by hooking them up to a different destination directory.

I'd be curious if you envisioned one of these, or something else.

[scottpgallagher]

I like the first way more cause with the second method if it's configured in the tbot.yaml (if that's what your mentioning) then someone who hacks into the box that has creds for those box could easily override that config or just straight leverage those creds to access additional resources.

[timothyb89]

We almost support this with where clauses on RBAC rules, but it only applies to Teleport RBAC resources and not like, servers/apps/databases/k8s clusters/etc:

kind: role
version: v5
metadata:
  name: example
spec:
  allow:
    resources: [node]
    verbs: [list]
    where: 'name == "example"'

There's been some improvements here lately with dynamic impersonation and SSH session RBAC but it still doesn't quite accomplish the ask.

I could see this syntax extended to support limiting new ssh/app/db/etc sessions though it wouldn't be a small lift.

[timothyb89]

Per another discussion about using where clauses for RBAC usage, per @nklaassen it looks like it doesn't work even for proper RBAC resources as most endpoints don't plumb through the resource into the where parser context: https://github.com/gravitational/teleport/blob/448b52e9a374fac9743afa45741ffa7bce2651e2/lib/auth/auth_with_roles.go#L3194

The rules are all evaluated today, but against an empty resource, making comparisons useless. This would be a relatively easy fix, at least.