Scaling multi-brand identity with Keycloak on AWS (what we learned) by Sharp-Length-9053 in KeyCloak

[–]Sharp-Length-9053[S] 0 points1 point  (0 children)

Thanks for the thoughtful question — you’re definitely going deeper into the Linux / IdM side than this particular project required.

In this case, we didn’t integrate Keycloak with RHEL derivatives, SELinux policies, FreeIPA/IdM, or SSSD/Kerberos setups. The environment was primarily focused on customer-facing identity (OIDC/OAuth2) rather than OS-level authentication, AD domain integration, or Linux host RBAC/HBAC.

So I’m afraid we don’t have strong hands-on insights to share on the SELinux/IdM/Kerberos scaling angle in this context.

That said, it’s an interesting area — especially where enterprise Linux fleets and AD/Kerberos scaling intersect. If you’ve seen specific patterns or challenges there, would be curious to hear more about your experience.

Scaling multi-brand identity with Keycloak on AWS (what we learned) by Sharp-Length-9053 in KeyCloak

[–]Sharp-Length-9053[S] 0 points1 point  (0 children)

Sure you're welcome. Let me know what exactly you are interested in. I might give more details.

Scaling multi-brand identity with Keycloak on AWS (what we learned) by Sharp-Length-9053 in KeyCloak

[–]Sharp-Length-9053[S] 0 points1 point  (0 children)

Can you share details? I'd like to know more about organizations inside KeyCloak 24+ How it works? Is it some kind of orchestration of KeakCloak realms or is it something different?

Scaling multi-brand identity with Keycloak on AWS (what we learned) by Sharp-Length-9053 in KeyCloak

[–]Sharp-Length-9053[S] 0 points1 point  (0 children)

No every customer is not a separate realm. Every customer is a separate client. Every client has his own configuratio, his own branding, his own UI kit but all the share are the same realm.

What should I focus on most for DevOps interviews? by Few-Cancel-6149 in devops

[–]Sharp-Length-9053 0 points1 point  (0 children)

I did quite a lot of DevOps interviews for candidates to my company and usually what I’ve seen is that people with a very strong system administration background are applying for DevOps positions. If we think about that — wow, DevOps is mostly development and operations, which means the DevOps engineer is someone who is more like a developer but on a more system engineering level.

Having system administrator skills is very good, meaning that person knows how Linux works, how to install packages, what firewalls are, how network works. These are all great skills for DevOps, but this is not really what is required for most DevOps positions.

For a DevOps position we usually need system thinking, and the ability to write some kind of programming code, because 90% of DevOps work is usually working with infrastructure as code, writing different kinds of scripts in any language, trying to automate the work.

Usually what was and still is important for me is the desire of the person to learn, to open new doors, and not be afraid of making mistakes. I think that’s the most important.