refactor(iam,identity): rename MachineAccount to ServiceAccount#583
Merged
Merged
Conversation
Contributor
Renames all MachineAccount and MachineAccountKey types, packages, CLI flags, REST storage keys, YAML resources, and kubebuilder markers to ServiceAccount and ServiceAccountKey throughout milo. This is a pre-GA breaking API rename aligning with industry-standard terminology (Kubernetes, GCP, AWS) for non-human machine identities. Key changes: - Go types: MachineAccount → ServiceAccount, MachineAccountKey → ServiceAccountKey - Package: internal/apiserver/identity/machineaccountkeys/ → serviceaccountkeys/ - REST path segment: /machineaccountkeys → /serviceaccountkeys - Feature gate: MachineAccountKeys → ServiceAccountKeys - CLI flags: --machineaccountkeys-provider-* → --serviceaccountkeys-provider-* - CRD, roles, protected-resources, resources-metrics, samples YAMLs all renamed - PolicyBinding Subject enum: MachineAccount → ServiceAccount - Regenerated zz_generated.deepcopy.go (×2) and zz_generated.openapi.go
kevwilliams
force-pushed
the
feat/rename-machineaccount-to-serviceaccount
branch
from
a3e3dbd to
8892eb8
Compare
scotwells
approved these changes
Apr 28, 2026
Contributor
|
@kevwilliams you'll need to adjust the zitadel provider as well. |
3 tasks
mattdjenkinson
added a commit
that referenced
this pull request
May 10, 2026
#608) ## Summary Mirrors 8e9843d for `UserIdentity`. Two changes, both on the milo side: 1. **`pkg/apis/identity/scheme.go`** — register `status.userUID` as a valid field selector for `UserIdentity`. Without this, milo's aggregator pre-rejects List requests with `"status.userUID" is not a known field selector: only "metadata.name", "metadata.namespace"` before they ever proxy to auth-provider-zitadel. 2. **`internal/apiserver/identity/useridentities/rest.go`** — forward the caller's field/label selectors to the backend instead of dropping them with `lo := metav1.ListOptions{}`. The auth-provider-zitadel REST handler relies on receiving `status.userUID` to switch into the SAR-gated cross-user code path. With the milo handler discarding it, even after milo-os/zitadel-provider#108 the cross-user path could not be reached for identities — the request never made it past milo. ## Why now The April 29 cross-user work (#583 here, milo-os/zitadel-provider#69) registered `Session` on both sides and intentionally deferred `UserIdentity` ("only Session is needed today"). Staff portal now wants the same lookup for IdP links — Google/GitHub/email — so support agents can see which providers a user has linked. End-to-end this PR + milo-os/zitadel-provider#108 unblock the staff-portal user detail page's read-only Account Identities card. ## Authorization Unchanged. The SAR check in auth-provider-zitadel remains the gate — `staff-users` already has `iam.miloapis.com/users.get` cluster-wide via `staff-user-manager-binding`, so no IAM changes needed. ## Test plan - [x] `go build ./pkg/apis/identity/... ./internal/apiserver/identity/...` — clean - [x] `go test ./internal/apiserver/identity/... ./pkg/apis/identity/...` — sessions tests still pass - [ ] Verify in staging: staff portal user detail page populates the Account Identities card with the *target* user's IdP links (currently shows the staff user's own — bug confirmed via apiserver logs and field-selector error) Pairs with milo-os/zitadel-provider#108. Refs milo-os/zitadel-provider#69.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
MachineAccount→ServiceAccountandMachineAccountKey→ServiceAccountKeythroughout all Go types, packages, CLI flags, REST storage keys, kubebuilder markers, and YAML configinternal/apiserver/identity/machineaccountkeys/→serviceaccountkeys/; REST HTTP path segment/machineaccountkeys→/serviceaccountkeys(breaking API change)MachineAccountKeys→ServiceAccountKeysand server flags--machineaccountkeys-provider-*→--serviceaccountkeys-provider-*zz_generated.deepcopy.go(×2) andzz_generated.openapi.goThis is a pre-GA breaking rename aligning with industry-standard terminology (Kubernetes, GCP, AWS) for non-human machine identities.
Out of scope (follow-on PRs needed)
graphql-gateway— queries the/machineaccountkeysAPI path directlymilo_machine_account*metric names--machineaccountkeys-provider-*flag namesTest plan
grep -r "MachineAccount\|machineAccount\|machine_account\|machine-account" --include="*.go" --include="*.yaml" --include="*.yml" | grep -v zz_generated | grep -v _test.goreturns zero resultsgo build ./...passestask generate:code && task generate:openapi:identityproduces no diff (already regenerated in this PR)