Login to Kublr with Microsoft Active Directory

Kublr, as a leading Kubernetes cluster management platform, offers organizations the ability to deploy and manage Kubernetes clusters seamlessly across multiple cloud providers. Its user-friendly interface, comprehensive feature set, and strong focus on security make it an indispensable tool for modern enterprises.

A standout feature of Kublr is its integration with Keycloak, enabling advanced centralized identity management, authentication and access control functionality out of the box. This capability empowers teams to efficiently manage RBAC (Role-Based Access Control) across Kubernetes clusters with ease. For enterprises using Microsoft Active Directory (AD), Kublr simplifies authentication and authorization processes, offering seamless integration that aligns with existing organizational security policies.

This article explores how Kublr integrates with Active Directory and leverages Keycloak to deliver secure, scalable, and easy-to-manage Kubernetes environments.

Procedure

Prerequisites:

  1. Kublr Control Plane with admin access to Keycloak.
  2. Microsoft Active Directory configured and accessible.

Active Directory configuration

The following Active Directory (AD) groups should be created to manage access within Kublr efficiently:

  1. KublrFullAdmins
    • This group grants full, unrestricted access to all actions across Kublr. Members can perform any operation without limitations.
  2. KublrClusterAdmins
    • Members of this group can manage Kublr clusters within the “dev” and “prod” spaces.
    • They have “admin” access to the kube-system namespace in those Kubernetes clusters.
    • However, they do not have access to application-specific namespaces and are not assigned the cluster-admin role.
  3. KublrDevelopers
    • This group has full access to the development (dev) Kublr space, including all clusters within it.
    • Members are granted access to the default, develop, and other application namespaces in Kubernetes.
    • Note: Specific Kubernetes namespaces must be explicitly allowed due to the granularity of Kubernetes RBAC policies.
  4. KublrProdOperations
    • Members of this group are restricted to the production (prod) Kublr space.
    • They can perform specific actions such as restarting pods in both the prod namespace and other application namespaces.
    • As with developers, access to Kubernetes namespaces must be explicitly granted via RBAC.
  5. KublrViewers
    • This group is designed for read-only access to both the dev and prod spaces.
    • Members can view all clusters and resources but cannot perform any modifications.

Also need to create an Active Directory (AD) account with read-only permissions to facilitate secure access to AD from Keycloak.

Keycloak configuration Steps:

In Kublr Control Plane:

  1. Login to Keycloak with admin account.

    KCP - Open Keycloak

In Keycloak:

  1. Make sure you have selected kublr-ui realm.

  2. In User Federation section, please select Add new provider and choose LDAP

    KCP - Keycloak - Adding LDAP provider

  3. Configure the connection settings:

    • Vendor: Active Directory
    • Connection URL: ldaps:// for secure connections. (Depending on MS AD DNS configuration, it is possible to use domain name ldaps://my-domain.org that should be resolvable to all MS Active Directory Domain Controllers)
    • Bind DN type: Simple
    • Bind DN: AD account name that should be used to connect Keycloak to Active Directory
    • Bind credentials: AD account password
    • Edit mode: READ_ONLY (It is possible to use UNSYNCED mode with you need to make any changes that should not be replicated back to AD - for example, like Keycloak groups assignments)
    • Users CN: Active Directory domain DN where all user accounts are located, for example, CN=Users,DC=my-domain,DC=org
    • Username LDAP attribute: sAMAccountName
    • RDN LDAP attribute: sAMAccountName
  4. For Synchronization settings, enable the following:

    • Import users: ON
    • Periodic full sync: ON
    • Full sync period: 3600
    • Periodic changed users sync: ON
    • Changed users sync period: 600
  5. Save all changes, and then navigate to tab Mappers inside created User Federation provider.

    KCP - Keycloak - Adding mappers

  6. Using Add mapper button, add the following mapper:

    • LDAP Groups DN: CN=Users,DC=my-domain,DC=org

    KCP - Keycloak - Configure mapper

Kublr RBAC configuration

Please refer to Kublr RBAC documentation on how to configure Kublr RBAC.

In order to get the RBAC model implemented, we have the following Kublr Security roles and bindings configured:

Default alignedCenter alignedCenter alignedCenter alignedCenter aligned
AllSpacesViewerGlobalRoleSpace: listAllSpacesViewerKublrClusterAdmins
KublrDevelopers
KublrProdOperations
KublrViewers
KublrClusterAdminsGlobalRoleSpace: list, get
Cluster, Cluster/id: list, get, put
cluster/applications, cluster/proxy, cluster/metrics: *
Secret: list
KublrClusterAdmins-prod
KublrClusterAdmins-dev
prod
dev
KublrDevelopersGlobalRoleSpace, cluster, cluster/config, cluster/proxy, cluster/dashboard, cluster/terminal, cluster/id, cluster/metrics: list, getKublrDevelopersdev
KublrProdOperationsGlobalRoleSpace, cluster, cluster/config, cluster/proxy, cluster/dashboard, cluster/terminal, cluster/id, cluster/metrics: list, getKublrProdOperationsprod
KublrViewersGlobalRoleSpace, cluster, cluster/config, cluster/proxy, cluster/dashboard, cluster/terminal, cluster/id, cluster/metrics: list, getKublrViewers-prod
KublrViewers-dev
prod
dev

The following roles and role bindings have been configured in the existing clusters:

EnvironmentRoleDescriptionRole BindingNamespaceNotes
Control planeN/ANo specific configuration, as this Kubernetes cluster should be accessed only by KublrFullAdmins membersN/AN/AN/A
DEVClusterOverviewnodes: listClusterOverviewGlobalTo groups:
KublrDevelopers
KublrViewers
Allows members of these groups to see cluster metrics and “instances” tab. Required for collecting nodes list and metrics (CPU, memory, storage).
adminPredefined K8s roleKublrDevelopers-defaultdefaultAdmin role for default namespace for group KublrDevelopers.
ViewPredefined K8s roleKublrViewers-defaultdefaultViewer role for default namespace for group KublrViewers.
adminPredefined K8s roleKublrDevelopers-developdevelopAdmin role for develop namespace for group KublrDevelopers.
ViewPredefined K8s roleKublrViewers-developdevelopViewer role for develop namespace for group KublrViewers.
PRODClusterOverviewnodes: listClusterOverviewGlobalTo groups:
KublrProdOperations
KublrViewers
Allows members of these groups to see cluster metrics and “instances” tab. Required for collecting nodes list and metrics (CPU, memory, storage).
adminPredefined K8s roleKublrProdOperations-defaultdefaultAdmin role for default namespace for group KublrProdOperations.
ViewPredefined K8s roleKublrViewers-defaultdefaultViewer role for default namespace for group KublrViewers.
adminPredefined K8s roleKublrProdOperations-prodprodAdmin role for prod namespace for group KublrProdOperations.
ViewPredefined K8s roleKublrViewers-prodprodViewer role for prod namespace for group KublrViewers.

Seamless Integration with Directory Services

Kublr offers seamless integration with a variety of directory services, including Active Directory, FreeIPA, and OpenLDAP. This flexibility ensures that your organization can leverage existing authentication systems to manage user access and permissions efficiently.

Integrating Kublr with these services is a straightforward process, requiring minimal effort. The steps are consistent across different directory services, with only minor adjustments to attribute names based on the specific schema used by your directory. For instance, FreeIPA or OpenLDAP might use custom attribute mappings, but Kublr’s configuration flexibility ensures a smooth setup.

With this robust compatibility, Kublr not only simplifies the integration process but also enhances security by aligning with your enterprise’s centralized identity management. This allows teams to manage access seamlessly, enforce policies, and maintain compliance with organizational standards.

No matter which directory service you use, Kublr’s intuitive interface and comprehensive documentation make the integration process effortless. By supporting a wide range of directory services, Kublr ensures that your Kubernetes environment is fully equipped to meet the demands of modern enterprise operations.

Conclusion

Integrating Active Directory with Kubernetes can be a daunting task, but Kublr makes it simple, secure, and scalable. By leveraging Keycloak, organizations can streamline authentication, automate access control, and ensure compliance with corporate security policies. Whether you’re managing one cluster or dozens across multiple clouds, Kublr provides the tools you need to succeed.

To learn more about Kublr and its advanced features, visit Kublr’s website.

See also