ACL tokens as generated by Consul look like UUIDs, but aren't. Some examples:
$ consul acl bootstrap
AccessorID: f9a399a4-6a65-8013-1562-f2bff96dfb9e
SecretID: 6b70bb47-0156-23bf-2d43-88c150c4fd94
Description: Bootstrap Token (Global Management)
Local: false
Create Time: 2018-11-22 13:19:24.522336745 +0000 UTC
Policies:
00000000-0000-0000-0000-000000000001 - global-management
$ uuid -d f9a399a4-6a65-8013-1562-f2bff96dfb9e
encode: STR: f9a399a4-6a65-8013-1562-f2bff96dfb9e
SIV: 331827231573401357665207318657515781022
decode: variant: reserved (NCS backward compatible)
version: 8 (unknown)
content: F9:A3:99:A4:6A:65:00:13:15:62:F2:BF:F9:6D:FB:9E
(not decipherable: unknown UUID version)
$ uuid -d 6b70bb47-0156-23bf-2d43-88c150c4fd94
encode: STR: 6b70bb47-0156-23bf-2d43-88c150c4fd94
SIV: 142812731233350941909964840929348353428
decode: variant: reserved (NCS backward compatible)
version: 2 (unknown)
content: 6B:70:BB:47:01:56:03:BF:2D:43:88:C1:50:C4:FD:94
(not decipherable: unknown UUID version)
I'd expect the documentation to either state that these UUID looking things aren't really UUIDs, or that consul generates valid (v4?) UUIDs.
v1.4.0
@lmb the code generating those is probably similar to what I encountered in Vault at hashicorp/vault#1707. _If they were_ actual UUIDs that'd be quite insecure.
https://github.com/hashicorp/go-uuid
Generates UUID-format strings using high quality, purely random bytes. It is not intended to be RFC compliant, merely to use a well-understood string representation of a 128-bit value. It can also parse UUID-format strings into their component bytes.
They should invent a new term for this, like "4+2+2+2+6 byte integer"
@nodakai UUIDoid :D
Opened https://github.com/hashicorp/consul/pull/5014 to clarify API generated UUIDs are not RFC compliant. Best place I could find for this was the API index page.
Most helpful comment
@nodakai UUIDoid :D