From fa363256189c14f6b32c88e8d60ffd2f66659e3e Mon Sep 17 00:00:00 2001 From: William Brown <william@blackhats.net.au> Date: Sat, 29 Mar 2025 14:58:45 +1000 Subject: [PATCH] Ideas about service accounts --- .../developers/designs/service_accounts.md | 119 ++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100644 book/src/developers/designs/service_accounts.md diff --git a/book/src/developers/designs/service_accounts.md b/book/src/developers/designs/service_accounts.md new file mode 100644 index 000000000..e960d9d4d --- /dev/null +++ b/book/src/developers/designs/service_accounts.md @@ -0,0 +1,119 @@ +# Service Account Improvements - 2025 + +Initially when service accounts were added to Kanidm they were simply meant to be "detached" +accounts that could be used for some API access to Kani, or some other background tasks. + +But as the server has evolved we need to consider how we can use these in other ways. + +We have extented the OAuth2 client types to now almost act like a service account, especially +with the behaviour of things like a client credentials grant. + +At this point we need to decide how to proceed with service accounts and what shape they could +take in the future. + +## Prior Art + +* (Microsoft AD-DS Service Accounts)[https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-service-accounts] +* (FreeIPA Service Principals)[https://www.freeipa.org/page/Administrators_Guide#managing-service-principals] + +Note that both of these have some kerberos centric ideas as KRB requires service accounts to mutually +authenticate to clients, which means they need to maintain credentials. This is different to our needs, +but there are still some ideas in these docs worth knowing about and considering like group managed +service accounts (gMSA). + +## High Level Suggestions + +There are the ideas today that I have - there may be others! + +* Service Accounts can have attached roles. +* Keep concerns separate. +* Bit of A, bit of B, cleanup. + +## Current state of affairs + +We have: + +* Break glass accounts are service accounts, may not have delegated management. +* OAuth2 is not a service account, supports delegated management. +* Service accounts can be group or user managed. +* Applications (To Be Introduced) is an extension of a Service account. + +From this we can see that we have some separation, but also some cross over of functionality. +break glass isn't delegated, but service account is, OAuth2 isn't an SA, but Applications are. + +## Attach roles to service accounts. + +In this approach we centre the service account, and allow optional extension of other concerns. This +would make OAuth2 applications an extension of a service account. Similar Application as well. + +This would mean that we create a service account first, then need a way to extend it with the +application or oauth2 types. + +PROS: + +* OAuth2 applications get the ability to have api tokens to kani for other functionality +* Fullstacks like a mail server get a single SA that does everything +* These whole stack service accounts get access to every auth type and feature available + +CONS: + +* Makes the API around service accounts a bit messier +* Compromise of the SA or SA Manager may lead to higher impact due to more features in one place +* May be confusing to administrators +* More "inheritance" of schema classes, when we may want to try to simplify to single classes in line with SCIM. +* Harder to audit capabilities + +## Separate Concerns + +In this approach we split our concerns. This is similar to today, but taken a bit further. + +In this example, we would split Application to *just* be about the concern of an authentication +domain for LDAP applications. OAuth2 stays as *just* a configuration of the client and it's behaviour. + +We would change the break glass accounts to be a separate type to Service Account. Service Account +becomes closer to the concept of a pure api access account. The break glass accounts become a +dedicated "emergency access account" type. + +PROS: + +* Similar to today, only small cleanup needed +* Separation of concerns and credentials limit's blast radius of a possible compromise. +* Easier auditing of capabilities of each account + +CONS: + +* More administrative overhead to manage the multiple accounts +* Stacked applications will need mulitple configurations for a role - OAuth2, LDAP application, Service accounts for example in an email server with a WebUI. + +## Bit of A, bit of B, cleanup + +Rather than fully merge all the types, or fully split them, have a *little* merge of some bits, allowing +some limited extension of actions to specific actors. + +OAuth2 and Applications would gain the ability to have API tokens associated for some tasks and +could act on Kanidm, but they wouldn't be fully fleshed service accounts. + +| | Api Token | OAuth2 Sessions | Interactive Login | +|-----------------|------------------|------------------------------|---------------------| +| OAuth2 | Yes | Via Client Credentials Grant | No | +| Application | Yes | No | No | +| Service Account | Yes (rw capable) | Yes (via session grant (TBD) | Yes (to be removed) | +| Break Glass | No | No | Yes | + +PROS: + +* Minimises changes to existing deployments +* Grants some new abilities within limits to other roles +* While not as locked down as separate concern proposal, still minimises the risk of compromise of an SA + + +CONS: + +* Requires admins to have multiple accounts in some contexts (as above). +* Auditing requires knowledge of what each roles capabilities are + + + + + +