Support device enrollment tokens under `tctl tokens`

[codingllama]

Device enrollment tokens are a separate entity from other tokens, thus they aren't wired into tctl tokens functionality. This is, in principle, by design, but it can cause confusion to customers - there is a fairly reasonable expectation that those tokens are just like the others.

This issue tracks that behavior and exists as a form of self-documentation, more than it is a promise of changes. Enrollment tokens are not backend-role-granting tokens, so they don't fit cleanly into tctl tokens. That said, we could conceivably fit them within that UX, pending product/UX feedback.

What would you like Teleport to do?

The tctl tokens family could be used to manage device enrollment tokens.

What problem does this solve?

This unifies more token types under tctl tokens and creates less confusion for end-users.

If a workaround exists, please include it.

tctl devices enroll is used create new enrollment tokens. Tokens are only valid for 1h by default and there can be only one device enrollment token at a time, so creating and discarding a new token effectively invalidates any other tokens.

There are no facilities to list existing tokens or to verify their remaining validity period.

[rikptrad]

Hi. Considering that tctl tokens does not show device enrollment tokens and that can be by design then somewhere inside tctl token command tree a command for that should be available - like tctl devices token ls. Manly because the machine (user) that is adding machines to the inventory will not be (potentially) the same of the machine that will be enrolled. There must be a way of validating the TTL of that device token.

[codingllama]

The general intent behind v12 enrollment tokens is that they are generated not-long before enrollment. For example, someone with the necessary permissions runs tctl devices enroll --asset-tag=MAC_SERIAL_NUMBER, and then sends the fresh token to the user doing the enrollment. Enrollment is understood to be essentially a manual process at that stage.

Jamf integration is scheduled for an upcoming v13 version, and with it we will land "auto-enrollment" as well. That may be also be an option for you, regardless of using Jamf. (Happy to further explain if it sounds interesting to you.)

I'm curious about what your intended enrollment process is. What would you do differently if you knew the token TTLs?

[rikptrad]

This is a very simple organisational issue. :) We have teams in very different timezones. It is not guarantee that the person that generate the token works on the same timezone that the person that will enrol the machine using the token. Your rational is absolutely flawless: we also see it as a manual process kinda of onboarding task.
I would be happy just with the indication that if the enrolment fails was due the expired token. If this error treatment is already in place then I'm happy.

[codingllama]

We have teams in very different timezones. It is not guarantee that the person that generate the token works on the same timezone that the person that will enrol the machine using the token.

We could let you configure the TTL for enrollment tokens, so you can work with a window larger than 1h. That should make it easier if there's little to no overlap between the different enrollment actors.

Auto-enrollment, to be released soon, allows tsh to automatically issue enrollment tokens for registered devices. If that seems like a good option, it could make enrollment almost free for you - you only need to tctl devices add the serial numbers beforehand.

How do the options above sound?

I would be happy just with the indication that if the enrolment fails was due the expired token. If this error treatment is already in place then I'm happy.

I believe the user would see a an "invalid device enrollment token" error. If you can look at server-side metrics, failures under the teleport.devicetrust.v1.DeviceTrustService.EnrollDevice RPC are also a strong indication of invalid/expired tokens (although it's not guaranteed, it's harder to fail enrollment in other ways).

[rikptrad]

Off course that having automatic enrollment is super neat. The teleport "admin" adds the device to the inventory and the user makes the enrollment using tsh

[strideynet]

I'm not sure I'm keen on this - token as a word/concept/resource type is already pretty overloaded in Teleport and anything we can do to keep new things separate from this is going to make it easier when (if??) we fix this messy naming in future.

[rikptrad]

I can understand and perfectly accept that concept/design has to be keept simple and with boundaries. For me, in customer shoes and eyes, it is the operation side that has my heart. I must be able to execute the enrolment and debug it, if necessary.

[codingllama]

Just wanted to mention here that, as of v13.2, auto-enroll is out. Docs here: https://goteleport.com/docs/access-controls/device-trust/auto-enrollment/?scope=enterprise.

[codingllama]

I think this is unlikely to get addressed, so I'm closing it. Let me know if you think otherwise.