CN115622737A

CN115622737A - Service authority framework based on kubernets

Info

Publication number: CN115622737A
Application number: CN202211130608.7A
Authority: CN
Inventors: 林世琴; 陈晓冲
Original assignee: Kaientai Nanjing Technology Co ltd
Current assignee: Kaientai Nanjing Technology Co ltd
Priority date: 2022-09-16
Filing date: 2022-09-16
Publication date: 2023-01-17

Abstract

The invention provides a service authority framework based on kubernets, which comprises an application end, a service end, basic service and kubernets, wherein the application end is connected with the service end through a network; the application end comprises an application end group/role/user architecture, and the service end comprises a service end group/service account architecture; the basic service comprises an LDAP service and a keylog application; the kubernets are used for constructing basic services; the application terminal is deployed on the kubernets and carries out authority design based on a group/role/user architecture. The beneficial effects of the invention are: maintenance management work of internal accounts, roles and authorities of the enterprise can be unified, and all internal application systems are organized and maintained uniformly, so that the authentication processing flow can be controlled and intervened; the management complexity of the account number authority system in the enterprise is reduced.

Description

Service authority framework based on kubernets

Technical Field

The invention relates to the technical field of authority management, in particular to a service authority framework based on kubernetes.

Background

A classical rights management model is generally designed according to a role-Base-Access-Control (RBAC) manner, and maintains relationships among accounts, groups, roles, and resources, where a role (role) is a set of rights, each role at least includes one right, one user may have multiple roles, each user at least plays one role, one role has multiple users, and users and roles are in a many-to-many relationship.

The standard RBAC privilege model consists of 4 sub-models, namely a basic model RBAC0 (Core RBAC), a role hierarchy model RBAC1 (hierarchy RBAC), a role restriction model RBAC2 (Constraint RBAC) and a unified model RBAC3 (combinations RBAC)

RBAC0 defines the smallest set of elements that can form a RBAC control system, and RBAC0 is the most basic and most core model and consists of five parts: user (user), role (role), permission (Permission), session (Session), operations (operations OPS).

RBAC1 introduces inheritance relationship between roles, and the inheritance relationship between roles can be divided into general inheritance relationship and limited inheritance relationship. Generally, an inheritance relationship only requires that a role inheritance relationship is an absolute partial order relationship, and multiple inheritance between roles is allowed. The restricted inheritance relationship further requires that the role inheritance relationship be a tree structure.

The RBAC2 model adds the responsibility separation relation. The separation of responsibilities includes static and dynamic separation of responsibilities. Constraints, along with user-role-privilege relationships, determine the access permissions of users in the RBAC2 model.

RBAC3 is a collection of RBAC1 and RBAC2, so RBAC3 is a comprehensive authorization model with both role hierarchy and constraints.

The inside RBAC authentication mechanism of Kubernets uses rbac.authorization.k.8 s.io API group to drive the authentication decision, and the dynamic policy configuration is carried out through the Kubernets API.

Kubernets' RBAC API declares four kubernets objects: role, cluster role, role Binding and cluster role Binding. Wherein a role or cluster role contains a set of rules representing associated permissions. These permissions are purely additive (there is no rule rejecting an operation). Roles are always used to set access rights within a certain namespace.

In contrast, a cluster role is a resource of a cluster scope. The names of these two resources are different (roles and cluster roles) because the kubernets object is either namespace-scoped or cluster-scoped, not both.

However, for applications and services deployed on kubernets, at present, only the RBAC inside kubernets can be set, and the implementation is performed based on the RBAC model inside kubernets, but for applications and services deployed on kubernets in a kubernets containerization framework, a unified authority framework model is not used for management at present, so that each application and service needs to be managed independently.

Disclosure of Invention

The invention aims to provide a service authority architecture based on kubernets, which can provide verification modes in various modes in combination with application and service of LDAP and kubernets, can perform related control and intervention on an authentication processing flow, and reduces the management complexity of an account authority system in an enterprise.

In order to achieve the purpose, the invention provides the following technical scheme: a service authority architecture based on kubernets comprises an application end, a service end, basic service and kubernets; the application end comprises an application end group/role/user architecture, and the service end comprises a service end group/service account architecture; the basic service comprises an LDAP service and a keylog application; the kubernets are used for constructing basic services; the application end is deployed on the kubernets and carries out authority design based on a group/role/user architecture.

Further, the application side performs fusion of service authority and kubernets authority through LDAP service and keylock application.

Further, the fusion of the service authority and the kubernets authority by the application terminal through the LDAP service and the keylock application includes:

each application authority of the application terminal establishes a mapping relation with users/groups/roles of different domains in the keylock application,

a mapping is then established by the users/groups/roles of the different domains in the keylock application with the users/groups/roles of the LDAP service,

and finally, establishing a mapping relation between the user/group/role of the LDAP service and the service account/group/role/cluster role of Kubernets.

Further, the integration of all service authorities of the server and Kubernets authority is completed through LDAP service.

Further, the fusion of each service authority of the server with the kubernets authority through the LDAP service includes:

the service account/group/role of the service end establishes mapping relation with the user/group/role of the LDAP service,

a mapping is then established by the user/group/role of the LDAP service with the service account/group/role/cluster role of kubernets.

Compared with the prior art, the invention has the beneficial effects that: maintenance management work of internal accounts, roles and authorities of the enterprise can be unified, and all internal application systems are organized and maintained uniformly, so that the authentication processing flow can be controlled and intervened; the management complexity of an internal account authority system of an enterprise is reduced.

Drawings

FIG. 1 is an overall architecture diagram of the present invention;

FIG. 2 is a diagram of an application permission mapping relationship of the keylog service, the LDAP service and the kubernets in the present invention;

FIG. 3 is a service permission mapping of LDAP service and kubernets in the present invention;

FIG. 4 is an architectural diagram of kubernets in accordance with the present invention;

FIG. 5 is a diagram of an account architecture in accordance with the present invention;

FIG. 6 is a block diagram of LDAP based ND design of the present invention;

FIG. 7 is a diagram of a domain model architecture for Keycoak in the present invention;

FIG. 8 is a schematic diagram of LDAP, keycoak and Gitlab applications deployed to Kubernets in accordance with the present invention;

FIG. 9 is a schematic illustration of the ND structure of LDAP in the present invention;

FIG. 10 is a schematic diagram of the combined configuration of Keycoak and LDAP in the present invention;

FIG. 11 is a diagram illustrating the contents of Group synchronization after the successful combination of Keycoak and LDAP in the present invention;

FIG. 12 is a schematic diagram of the configuration of the combination of Keycoak and Gitlab in the present invention;

FIG. 13 is a schematic diagram of the configuration of RoleBinding and Cluster RoleBinding in Kubernetes in the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention are clearly and completely described below with reference to the accompanying drawings, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

As shown in fig. 1, a kubernets-based service authority architecture constructs an LDAP service and a keylock application through a kubernets containerized application, and the LDAP service is mainly used for maintaining all account systems, organizational structures, and roles inside an enterprise. Account/group/role architecture as shown in fig. 5, account/group/role is managed and maintained in LDAP services. The DN design principle of LDAP is shown in fig. 6. The application authority control is uniformly performed in Keycloak, the Keycloak accesses and maintains basic information such as account numbers/groups/roles through an LDAP service, then different applications are distinguished through the domain setting of the Keycloak, and authority isolation and multiplexing among the applications are achieved, and the domain model setting of the Keycloak is shown in figure 7.

keylog provides various authentication services outwards based on LDAP service, and provides uniform system management for account maintenance.

The service authority architecture comprises an application end, a service end, basic service and kubernets; the application end comprises an application end group/role/user architecture, and the service end comprises a service end group/service account architecture; the basic service comprises an LDAP service and a keylog application; the kubernets are used for constructing basic services; the application end is deployed on the kubernets and carries out authority design based on a group/role/user architecture.

As shown in fig. 2, the application side performs fusion of the service authority and the kubernets authority through the LDAP service and the keylock application, and the specific process includes:

and establishing a mapping relation between each application authority of the application end and users/groups/roles in different domains in the keylock application. A mapping is then established between users/groups/roles of different domains in the keylock application and users/groups/roles of the LDAP service. And finally, establishing a mapping relation between the user/group/role of the LDAP service and the service account/group/role/cluster role of Kubernets. The purpose of linkage control of the authority of the account in the application and service and the authority on the Kubernets cluster is achieved.

As shown in fig. 3, each service right of the server is merged with the kubernets right through the LDAP service. The specific process comprises the following steps:

and the service account/group/role of the service end establishes a mapping relation with the user/group/role of the LDAP service. A mapping is then established by the user/group/role of the LDAP service with the service account/group/role/cluster role of kubernets. And finally, the purpose of linkage control of the authority of the account in the authority and the authority on the Kubernetes cluster is realized.

As shown in FIG. 4, kubernets' cluster is divided into compute and storage clusters, including PaaS, iaaS, and Hardware. The Kubernetes + Docker serves as IaaS basic platform service, RBAC authority management is achieved by combining LDAP and KeyCloak, and LDAP service and KeyCloak authentication service are constructed on Kubernetes; internal applications such as Wiki, redmine, gitlab, file applications, interface management platforms, kuboard management platforms, jenkins, harbor, etc. can be integrated with keylock and LDAP, thereby completing unified authentication control.

In the present invention, kubernets is an open source system for automatically deploying, extending and managing containerized (containerized) applications, which is an open source version of the Google in-house tool Borg.

RBAC refers to (Role-Based Access Control) Role-Based Access Control.

LDAP refers to the lightweight directory access protocol. The Lightweight Directory Access Protocol (LDAP) is an open, neutral, industry-standard application Protocol that provides Access control and maintains Directory information for distributed information via IP protocols.

Keylock refers to software that opens the source for identity authentication and access control.

The invention is not described in detail, but is well known to those skilled in the art.

The building process of the whole architecture is described below by taking gitlab as a case.

As shown in fig. 8, LDAP, keyloak and gitlab services are first built and deployed on kubernets.

Then, the employes, groups and roles are configured on the LDAP according to the ND design structure of fig. 6, and the final structure is shown in fig. 9.

And then, configuring user authentication and LDAP for connection in a domain KNT-OAS corresponding to Keycoak, and importing all groups, roles and existing accounts on the LDAP after the connection authentication is successful, as shown in fig. 10 and 11.

And then setting the gitlab, setting the gitlab corresponding to the keylog, and configuring the generated key to the gitlab service, so that the LDAP account number and the account number on the gitlab correspond, as shown in fig. 12.

As shown in fig. 5, the Group structure corresponds to the item contents in groups in fig. 9, user corresponds to the items in employes in fig. 9, and the Role structure corresponds to the items in roles in fig. 9. Session corresponds to the Session created in keylog when gitlab logs in, while Permission corresponds to the action of Kubernetes. The configurations of rollering and clusterrollering are set for the corresponding group on kubernets, as shown in fig. 13.

After the configuration is completed, users are added through Keycoak and associated with Group and Role on LDAP, so that as a develoop developer, the user can log in the gitlab to perform related CI/CD operation, and has operation authority under corresponding namespace on kubernets.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The above is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, several modifications and variations can be made without departing from the technical principle of the present invention, and these modifications and variations should also be regarded as the protection scope of the present invention.

Claims

1. A service authority framework based on kubernets is characterized in that: the system comprises an application end, a service end, basic service and kubernets; the application end comprises an application end group/role/user architecture, and the service end comprises a service end group/service account architecture; the basic service comprises an LDAP service and a keylog application; the kubernets are used for constructing basic services; the application end is deployed on the kubernets and carries out authority design based on a group/role/user architecture.

2. The kubernets-based business rights architecture of claim 1, wherein: and the application terminal performs fusion of service permission and kubernetes permission through LDAP service and keylogging application.

3. The kubernets-based business rights architecture of claim 2, wherein: the application side carries out fusion of the service authority and the kubernets authority through the LDAP service and the keylog application, and the fusion comprises the following steps:

each application authority of the application end establishes a mapping relation with users/groups/roles of different domains in the keylock application,

a mapping is then established between users/groups/roles of different domains in the keylock application and users/groups/roles of the LDAP service,

4. The kubernets-based business rights architecture of claim 1, wherein: and the integration of all service authorities of the server with Kubernetes authorities is completed through LDAP service.

5. The kubernets-based business rights architecture of claim 4, wherein: the fusion of each service authority of the server side and the Kubernetes authority through the LDAP service completion comprises the following steps:

the service account/group/role of the service end establishes a mapping relation with the user/group/role of the LDAP service,