Paul Hammant's Blog: A Purpose in a Token

Context: Playing with Pulumi for a homelab setup, and thoughts on tokens generally.

Pulumi needs access tokens to use. Here’s what that looks like:

It’s great that Pulumi is forcing you to choose a term in token acquisition. Later there’s a place you can add more info (description etc). What I’d really love (I can’t find my prior Tweet on this) is that term to be mandatorily placed in the middle of the token, so it’s apparent where you find it again within your larger “systems”.

That’d be like this:

I’ve edited the DOM for that pic - when it was gen’d for me by Pulumi it did’nt have the -homelab- in it and was a different SHA1. So I changed it and took a pic.

More

I’d like tokens within an hierarchichal organization, not just a convention as I did above. Say in a company, I’d be making things the “paul dev env” (my mental model). But the IT department would wish me follow an ontology like env/dev/phammant/1/redis or adhoc/phammant/exprmnt7/spark12. And the token’s generated would be 965c5c939235909-env/dev/phammant/1/redis-479d84fd7e0a862a893c6b5b1 and e89c15ae4e272ba504e9bad-adhoc/phammant/exprmnt7/spark12-e1b052149e35f9aef.

So I could read a guide on Confluence Sharepoint Notion and do it that way … Or I could be within the organizational account and be constrained to choosing “adhoc/phammant” or “env/dev/phammant” from a dropdown before specifyin the bits to the riht fo that. Or via a REST API, given we DevOps these days and clicking thru UIs isn’t DevOps. Note that I’ve gone beyond Pulami’s use of tokens there in that this is more about tokens for big-ass cloud infra leasing.

I say purpose in the title, but policy works too. I’m reminded of “Branch: only when necessary, on incompatible policy, late, and instead of freeze” (Laura Wingerd & Christopher Seiwald of Perforce in 1998’s High-Level SCM Best Practices white paper). I’ve been introducing that to devs I work with for 20 years now. Seems that applies to these tokens too.