Using Keycloak to secure human as well as machine actors

I am developing a microservice-based project that will have human users logging in the system as well as machines directly connecting with the microservices.

I will explain the scenario better with an example. Take, for example, AWS(or any cloud provider). Human users are logging into the system with username-password. These users generate access-key secret-key pair that will be used by the machines to communicate with AWS resources.
One of the approaches to configuring this in Keycloak is:

  1. Human Users: These will be configured as Users in Keycloak
  2. Machine to machine communication: Machines will be configured as Clients in Keycloak with Service Account Enabled.

With this approach, we will have to dynamically create new clients for every new machine(or pool of machines) connecting to the server. First of all, is it a problem at all or is it normal? As I have observed, typically, clients in Keycloak are either frontend channels or microservices(configured as a service account). Basically, clients are static and not dynamically added(based on my observation).

  1. Should we dynamically generate Clients in Keycloak?
  2. Alternate Approaches: Please share your ideas/approaches to secure the system described above.
1 Like

For IMHO the biggest issue is service-account- hardcoded values….

I don’t have experience with your usecase, but I know that Keycloak does have tools for dynamic client registration. Read more at Securing Applications and Services Guide.

From your brief description, I imagine a system where machines come online and dynamically register themselves with Keycloak. Obviously I don’t really know your requirements, but I would have thought to just statically register one client and maybe have multiple machines use the same client. If different clients need different permissions, I might register more clients, but you might not get much added security from this. Dynamic registration and de-registration of machines and clients seems like an unnecessary hassle.

On the subject, I’ve noticed that Keycloak seems to implement “service accounts” using regular user accounts. The service accounts don’t show up on user searches, but if you know the ID of the account (which you can find by checking the network tab), you can load the user and even set a first and last name. Personally I find this kind of useful to know, because it supports the simple idea that a service account is really just a machine user.

typically i’ve seen per-service (vs per-machine) clients in modern microservice architectures. so your backend could (for example) fire up N instances and use an instance/service role to access appropriate secrets that leverage the service-specific client/service account. maybe this is all you need, and it’d be easier to manage (KISS).

if you truly need per-machine/instance clients the doc pointed to by @sharpedavid w/ client registration policies looks interesting. however, along with the policy you need to think about deregistration and perhaps reconciliation (if something goes wrong and stale clients build up) so this is more complexity i would avoid unless you have a technical or regulatory requirement that makes it unavoidable.

be sure to post back with how you decide to go and share your experience for the community!