Agent could auto-mint kubelet bootstrap-token when Arc/MI/SP credentials are available
- Dominant language
- Go
- Stars
- 14
- Forks
- 28
- Avg merge
- 4d 13h
- Merged PRs (30d)
- 12
Description
Hi team, third of three related observations on the Arc-mode kubelet auth path. This one is more enhancement than bug. Cross-links at the bottom.
## What we observed
In Arc, MI and SP modes the agent already holds Azure credentials that can call the AKS RP. But in none of those modes does it appear to mint a kubelet bootstrap-token on the user's behalf. The operator has to either:
- Run `kubectl create token` (or apply a bootstrap-token Secret YAML) themselves and paste it into the agent config, or
- Rely on the MI exec-credential path (separate issue).
## Impact for our scenario
The shape of the customer story we're building toward is "operator stands in front of an edge device, runs one command, walks away." Asking them to also touch `kubectl` on the cloud side and paste a token back is an awkward handoff, since the agent already has all the ingredients to do it for them.
## One possible direction
When `bootstrapToken` is unset and the agent has Azure creds that can call the cluster, the agent could mint one itself:
1. Call `listClusterAdminCredentials` to get an admin kubeconfig (this Azure call already exists in v0.1.0).
2. Use it to create a bootstrap-token secret in `kube-system` with a short TTL (e.g. 1h, just enough for kubelet to come up and request its long-term cert).
3. Pass the token straight to kubelet's bootstrap kubeconfig.
This would also let folks Arc-onboard a device with no `kubectl` access at all, which is the common edge case. Worth documenting the required Azure RBAC scope clearly (`Microsoft.ContainerService/managedClusters/listClusterAdminCredential/action`).
Happy to test a prototype on the Pi rack.
Version tested: v0.1.0 (git 65d8d38).
---
## Related on this auth path (tightly coupled)
- #185 — Kubelet MI exec credential does not propagate Arc HIMDS env vars
- #186 — `validateExclusiveAuthSettings` treats Arc and bootstrap-token as mutually exclusive
---
## Other observations from the same Pi-rack edge demo
- #182 — Arc machine RG and AKS cluster RG must match (hard-coded in v0.1.0)
- #183 — Agent should preflight RBAC permissions before `assignRBACRoles`
- #184 — Hostname casing not normalized; PascalCase machine names fail node validation
- #185 — Kubelet MI exec credential does not propagate Arc HIMDS env vars
- #186 — `validateExclusiveAuthSettings` treats Arc and bootstrap-token as mutually exclusive
- #188 — `kube1` systemd-nspawn launcher passes `--network-veth` but actually shares host netns
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing the existing listClusterAdminCredentials call and the bootstrapToken handling described in the issue. Define the Azure RBAC and short-TTL bootstrap-token flow, then verify that the token reaches kubelet bootstrap without requiring kubectl.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, go
- Domain
- authentication, cloud
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100