Reasons for writing this article: at the moment, an investigation is in progress, and some of the collected and tested information will be useful for others. Perhaps someone will add some tips. Thank you.
There is a solve task I need to solve:
Keeping users/groups in the single directory.
Control access, based on group memberships in directory:
Access control to web applications via #oidc/#saml
Access control to vanilla #Kubernetes
SSH access control to bare-metal hosts - using SSH certificate technology if possible
Authorize users to other server applications such as #Vault, #PostgreSQL, #Kafka, #ClickHouse, #MongoDB
Being able to connect users from third-party organizations to certain resources based on group membership, etc
Ensuring that everything described above works, including the bare metal environment
At first glance, many #open-source products/technologies provide techniques, but the devil is in the details. This is the reason why businesses of the below-mentioned companies exist.
I don't see a big reason to pay for #teleport, #Okta, #JumpCloud, #OneLogin, and other commercial enterprise solutions at $15/user/month, considering our number of users. It's not particularly relevant.
There are nuances:
Azure AD - In #OIDC scopes issues, only group object IDs are provided, which is not very convenient to manage, regardless of whether it's Kubernetes RBAC or something else.
Google Workshop does not know how to give information about groups in OIDC at all
The original idea was to use #keycloak as an aggregator, but it was dropped due to the following reasons:
1. There are no free, productive quality SSH authorization solutions without LDAP. With LDAP - everything is okay - #sssd
2. Free IAM solutions OIDC/SAML:
Only Dex can work normally with group resolving from Azure & Google
Keycloak with varying success (you will have to manually copy the Azure AD object group IDs with mappers), for Google workplace exists a module for Google groups mapping (https://github.com/lunatech-labs/lunatech-keycloak-google-groups-mapper)
3. Keycloak user federation nuances:
#keycloak works nicely with Azure LDAP, all users/groups look like native
#keycloak doesn't work with Google LDAP because Google LDAP schema contains two (!!!) "cn" fields. #keycloak UI just dies:)
The following concept we are testing:
All users/groups live in Azure AD.
If necessary, external contractors can connect as additional iDPs to Azure External Identities.
SSH access to hosts: #sssd via LDAP (Azure Domain Services).
Vanilla Kubernetes (yes, our [c]rb will contain Azure Groups IDs), Vault will use Azure AD OIDC as iDP.
#PostgreSQL, #ClickHouse, etc. will use PAM/NSS from #sssd
Notes:
Perhaps I will try #Dex at the top of IAM and find new moments
I know about https://smallstep.com. I'm playing with that. Hopefully, I will replace SSSD with it.
It seems that #rancher works with any combination of #OIDC, #SAML, #Azure, #GoogleWorkspace, and controls RBAC in a good UI. I will test it.
The article will be updated as soon as the solution is finalized, tested, etc.
Tips and criticism are always welcome!
thank you!