Method and system for access control within a version management configuration of a computing cluster

Abstract

A method and system for checking authorization compatibility between a configuration management system and an orchestration system of a computing cluster is disclosed. The method includes identifying a request to approve a change in at least one file of the computing cluster; retrieving an identity of a user to perform the change from a repository of the configuration management system; obtaining a rejection or approval response received in response to a query provided to the orchestration system, the query regarding authorization to modify the at least one file using the identity of the user; entering the approval response into the configuration management system in response to the approval response to confirm that the checking of authorization compatibility is authorized; and sending a message to the configuration management system in response to the received rejection, the message indicating that the checking of authorization compatibility is not authorized.

Description

Technical Field

[0001] In some embodiments, the present disclosure relates to access control for version management configurations of an orchestration system of a computing cluster, and more particularly, to methods and systems for checking authorization compatibility between a configuration management system and an orchestration system of a computing cluster, although not exclusive.

Background Art

[0002] Container technology is based on packaging applications to operate in a state where dependencies are separated. Containers have fundamentally changed today's software development due to the compartmentalization of containers in computer systems.

[0003] Containers provide a logical packaging mechanism in which applications may be removed from the target environment in which they actually operate. This separation enables container-based applications to be developed easily and consistently regardless of whether the target environment is a dedicated data center, a public cloud, or even a developer's personal laptop. Developers focus on the logic and dependencies of their applications, while information technology (IT) operations teams can focus on the development and management of applications without worrying about the details of the applications, such as specific software versions and configurations specific to the application (app), so containerization realizes a clear separation of interests.

[0004] Containers enable applications and their dependencies to be packaged together into one unit that can be version-controlled, enabling easy replication of applications across a team of developers and machines within a cluster.

[0005] When combined with a service-based architecture, the overall units that developers are required to demonstrate become even smaller, and agility and productivity increase. All of this makes it easier to develop, test, deploy, and comprehensively manage applications.

[0006] Container orchestration is a management system that manages the lifecycle of containers, especially within a large and dynamic environment such as a composite cloud environment.

[0007] A versioning management system (also called a version control system) is a category of software tools that helps software teams manage changes to source code over time. Version control software records any modifications to the code in a unique database. If a development mistake is made, developers can roll back and compare the code to the previous version to help correct the mistake while minimizing confusion for all team members.

Summary of the Invention

[0008] The objective of the present disclosure is to describe a system and method for checking the authorization compatibility between a configuration management system and an orchestration system of a computing cluster.

[0009] The above and other objectives are achieved by the functions of the independent claims. Further implementations are apparent from the dependent claims, the description, and the figures.

[0010] In one aspect, the present disclosure relates to a method for checking the authorization compatibility between a configuration management system and an orchestration system of a computing cluster. The method includes identifying a request to approve at least one change in at least one file that defines the configuration of the computing cluster, and Retrieving the identification information of a user for performing at least one change from the repository of the configuration management system, and Obtaining a rejection response or an approval response received in response to a query supplied to an orchestration system, where the query relates to the right to change at least one file using the identification information of the user, obtaining; In response to the approval response, inputting the approval response to the configuration management system to confirm that it is approved to check authorization compatibility; In response to the received rejection, sending a message to the configuration management system, where the message indicates that it is not approved to check authorization compatibility, sending; including.

[0011] In a further implementation form of the first aspect, the method Analyzing at least one changed file to detect the objects and operations affected by the change; Accessing the orchestration system to verify that the retrieved user identification information is authorized to perform changes within the orchestration system and to apply the objects and operations affected by the performed changes, thereby checking authorization compatibility with the orchestration system; further includes.

[0012] In a further implementation form of the first aspect, the method Mapping between the user name of the configuration management system and the user name of the orchestration system of the computing cluster to check authorization compatibility between the configuration management system and the orchestration system of the computing cluster; further includes.

[0013] In a further implementation form of the first aspect, the configuration management system is a versioning management system.

[0014] In a further implementation form of the first aspect, the configuration management system is Git.

[0015] In a further implementation form of the first aspect, the orchestration system of the computing cluster is Kubernetes.

[0016] In a further implementation form of the first aspect, the configuration management system is part of the computing cluster.

[0017] In a further implementation form of the first aspect, in response to a received rejection, sending a message to the configuration management system includes one of the following notifying the user by the user interface that at least one change is not approved, responding to a request to approve the change with a comment or change request that is consistent with the authorization check compatibility, or adding a result file including one of them.

[0018] In a further implementation form of the first aspect, the method further includes applying at least one change to the computing cluster in response to an approval received from an orchestration system of the computing cluster for the user to execute at least one change. including further.

[0019] In a further implementation form of the first aspect, identifying a request to approve at least one change in at least one file is performed during the change review flow of the configuration management system.

[0020] In a further implementation of the first aspect, regarding the permission to execute multiple changes in at least one file, when a query is supplied to the orchestration system and some of the changes are approved and some are rejected, the computing cluster applies the approved part of the changes and notifies the user through the user interface about the part of the changes that are rejected.

[0021] In a second aspect, the present disclosure relates to a server having at least one processor that executes a method for checking authorization compatibility between a configuration management system and an orchestration system of a computing cluster. The server identifies a request to approve at least one change in at least one file that defines the configuration of the computing cluster, retrieves the identification information of the user for executing at least one change from the repository of the configuration management system, obtains a rejection response or an approval response received in response to a query supplied to the orchestration system, where the query relates to the permission to change at least one file using the identification information of the user, inputs the approval response to the configuration management system to confirm that checking authorization compatibility is approved in response to the approval response, sends a message to the configuration management system in response to the received rejection, where the message indicates that checking authorization compatibility is not approved, and is configured to perform the above.

[0022] In a further implementation of the second aspect, the server analyzes at least one changed file to detect the objects and operations affected by the change, Access the orchestration system, verify that the retrieved user identification information is authorized to perform changes within the orchestration system, and apply the objects and operations affected by the executed changes, thereby checking the authorization compatibility with the orchestration system and is further configured to perform.

[0023] In a further implementation of the second aspect, the server maps between the user name of the configuration management system and the user name of the orchestration system of the computing cluster to check the authorization compatibility between the configuration management system and the orchestration system of the computing cluster. is further configured to perform.

[0024] In a further implementation of the second aspect, at least one processor, as part of the configuration management system, executes a method for checking the authorization compatibility between the configuration management system and the orchestration system of the computing cluster.

[0025] In a further implementation of the second aspect, at least one processor, as part of the continuous integration continuous deployment (CICD) system, executes a method for checking the authorization compatibility between the configuration management system and the orchestration system of the computing cluster.

[0026] In a further implementation of the second aspect, at least one processor, as part of the computing cluster, executes a method for checking the authorization compatibility between the configuration management system and the orchestration system of the computing cluster.

[0027] In a third aspect, the present disclosure relates to a computer program product for checking authorization compatibility between a configuration management system and an orchestration system, the computer program product comprising: one or more computer-readable storage media, and program instructions collectively stored on the one or more computer-readable storage media wherein the program instructions include: program instructions for identifying a request to approve at least one change in at least one file defining the configuration of a computing cluster; program instructions for retrieving user identification information for performing at least one change from a repository of a configuration management system; program instructions for obtaining a rejection response or an approval response received in response to a query supplied to an orchestration system, the query being related to the right to change at least one file using the user identification information; program instructions for inputting the approval response to the configuration management system to confirm that checking authorization compatibility is approved in response to the approval response; program instructions for sending a message to the configuration management system in response to the received rejection, the message indicating that checking authorization compatibility is not approved; and

[0028] In a further implementation of the third aspect, the computer program product further includes: program instructions for analyzing at least one changed file to detect objects and operations affected by the change; program instructions for accessing the orchestration system to verify that the retrieved user identification information is authorized to perform changes in the orchestration system and to apply the objects and operations affected by the executed changes, thereby checking authorization compatibility with respect to the orchestration system; further includes

[0029] In a further implementation form of the third aspect, the computer program product further includes programming instructions for mapping between the username of the configuration management system and the username of the orchestration system of the computing cluster in order to check the authorization compatibility between the configuration management system and the orchestration system of the computing cluster.

[0030] Unless otherwise defined, all technical terms and / or scientific terms used in this specification have the same meaning as commonly understood by those skilled in the art to which the present invention pertains. Methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the present invention, but exemplary methods and / or materials are described below. In case of conflict, the patent specification including the definitions will control. In addition, the materials, methods, and examples are merely exemplary and not necessarily limiting.

[0031] With reference to the accompanying drawings, some embodiments of the present invention are described herein by way of example only. Next, referring specifically to the drawings in detail, the details shown are for illustrative explanation of embodiments of the present invention as an example. In this regard, the description incorporated with the drawings will clarify to those skilled in the art how embodiments of the present invention can be practiced.

Brief Description of the Drawings

[0032]

Figure 1

Figure 2

Figure 3

Figure 4

[0033] In some embodiments, the present disclosure relates to access control of the version management configuration of an orchestration system of a computing cluster, and more particularly, although not exclusively, to a method and system for checking authorization compatibility between a configuration management system and an orchestration system of a computing cluster.

[0034] The orchestration system is important for scaling and operating containers on any public cloud or private cloud or computing cluster. Deploying and updating an application to the orchestration system combines the container image, which is the application code, with a deployment configuration, such as the derived Pod definition in a YAML file that references the container image. From a security and compliance perspective, changes to both code and configuration should be audited and version-controlled.

[0035] A configuration management system is a system that ensures that all software and hardware assets owned by an enterprise are always known and tracked so that any future changes to these assets are known and tracked. The configuration management system maintains a computer system, servers, and software in a desired uniform state, thereby ensuring that the system operates as expected as changes are made over time.

[0036] A versioning management system or version control system is a system that records changes over time to a file or set of files so that a specific version can be called later.

[0037] The operation model for an orchestration system is a cloud-native continuous integration / continuous deployment (CI / CD) model. This model is a system in which all changes and updates to the deployment environment occur via changes to version control, based on a versioning management system. Such an operation model provides a set of practices that automatically orchestrate code and configurations for applications and environments. Instead of manually configuring the environment, all changes are automatically deployed when they are approved and merged into a new version. A versioning management system with an operation model for an orchestration system is an example of an implementation form of a configuration management system.

[0038] One of the problems in the operation model for an orchestration system based on a configuration management system, specifically a versioning management system, is access authorization. Specifically, the authorization of the configuration management system and the orchestration system is neither coordinated nor compatible. The differences are manifested in three aspects: the objects to be checked, the types of authorization checks, and the methods of performing authorization checks. The objects managed by the configuration management system are limited to, for example, repositories and files, while the orchestration system manages any objects defined in a fairly wide range. An example of this difference is clearly shown in the access authorization defined as the authorization permission of the configuration management system and the authorization check mechanism of the orchestration system. In the configuration management system, access authorization is limited to a small number of types of access authorization, such as read-only, read-write, and administrator, while the orchestration system has a fine-grained type of authorization check mechanism such as enumeration, reading, writing, deleting, and updating. The configuration management system is equipped with an authorization check access mechanism incorporated as part of the configuration management system, while the orchestration system includes several access authorization mechanisms. The access authorization mechanism of the orchestration system defines a model that enables various access authorizations such as per user, per object, and per operation.

[0039] Due to this difference, some of the operation models based on the management of configuration or versioning or both for the orchestration system define their own access models independently of the configuration or versioning or both management systems and the orchestration system. In this way, access authorization bypasses the access control of the "native" configuration or versioning or both management systems and the orchestration system and is managed internally by the operation model. As a result, the access authorization mechanism of the orchestration system becomes meaningless and burdens the developer or the operation model.

[0040] To avoid the access authorization mechanism of the orchestration system becoming meaningless and imposing a burden on developers, some versioning management-based operating models have decided to separate the versioning management flow (e.g., commit and merge) from the orchestration system and delay the time from authorization check to deployment. This has the drawback that approved changes within the versioning management system may potentially fail to deploy due to losing authorization.

[0041] Another solution is to use a single all-powerful user account operating under the operating model to enable all approved changes and apply them to the orchestration system, but this also makes the access authorization mechanism of the orchestration system meaningless.

[0042] Another alternative is, for example, to map between the user access authorization of the versioning management system and the access authorization of the orchestration. However, this does not work if the mapping is not a simple one-to-one mapping.

[0043] Therefore, it is necessary to provide a solution for checking the authorization compatibility between a configuration management system and an orchestration system of a computing cluster. This disclosure describes a system that maintains the access authorization mechanism of the orchestration system and integrates it into the change review flow of the configuration management system. This disclosure describes a system and method in which authorization checks are performed as part of the change review flow and against the authorizations defined within the orchestration system. The change review flow is a process in which changes in code files or configuration files or both are tested both automatically by running CI / CD tests and by being checked by other users, and the changes are reviewed before being merged into the main code file to verify that the changes are accurate. In this way, it is ensured that the changes are compatible with the state and authorizations of the cluster. The authorization check supports all the functions of the orchestration system, accesses the authorization mechanism (such as for each object type access, each user, and each operation, etc.), requires significant computing power, and does not require complex emulations that may be inaccurate for emulated systems. Authorizations and users are maintained in a single place that enables version control to be performed on both users and authorizations while everything is declaratively managed through configuration objects.

[0044] Before detailing at least one embodiment of the present invention, it should be understood that the present invention is not necessarily limited in its application to the details of the construction and arrangement of components or methods or both described in the following description and / or shown in the drawings or examples or both. The present invention is capable of being practiced or carried out in other embodiments or in various ways.

[0045] The present invention can be a system, a method, a computer program product, or a combination thereof. The computer program product may include one or more computer-readable storage media having computer-readable program instructions for causing a processor to execute aspects of the present invention.

[0046] A computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing.

[0047] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to respective computing / processing devices, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof.

[0048] Computer-readable program instructions can be executed entirely on a user's computer or computerized device or both, partially on a user's computer or computerized device or both, as a stand-alone software package, partially on a user's computer (or computerized device or both) and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer or computerized device or both via any type of network including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g., via the Internet through an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit for the execution of aspects of the present invention.

[0049] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0050] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram can represent a module, segment, or portion of instructions that include one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions recited in the blocks may be performed out of the order recited in the figures. For example, two blocks shown in succession may, in fact, be executed substantially in parallel depending on the functionality involved, or the blocks may sometimes be executed in the reverse order. It should also be noted that each block of the block diagrams or flowchart diagrams, or both, and combinations of blocks in the block diagrams or flowchart diagrams, or both, can be implemented by a dedicated hardware-based system that performs the specified functions or acts, or by a combination of dedicated hardware and computer instructions.

[0051] Next, reference is made to FIG. 1, which schematically shows the interaction of the configuration management system with the configuration management system 101 and an orchestration system 102 of a computing cluster (also called an orchestration system). The configuration management system 101 includes a code file 103 that defines the configuration of the computing cluster and is stored in the repository 108. The code file 103 includes a main code (usually called a master code or master branch) and a branch code that is a sub-code of the master code. When the team works on the code, each user in the team can work on the branch code separately and individually, and after the branch code is ready, the branch code is merged into the master code. Before merging the branch code into the master code, the branch code is tested to ensure that it operates correctly and accurately, and another user (usually a manager, operator, senior engineer, or someone familiar with the changed code) checks that the branch code is correct and appropriate. Each time a user modifies one of the code files 103, the modified code file is executed once, and the container 104 is built as part of a continuous integration (CI) process for unit and integration tests to verify that the code file is good. After the code file executes successfully and all tests are approved, the configuration file 105 is updated according to the modified code file, and when the modified code file and the modified configuration file are approved by other users, the code file, which is the branch code, is merged into the master code. When the master code is changed, the orchestration system 102 is updated by the configuration management system 101 to execute the updated configuration file for the updated master code.

[0052] Next, reference is also made to FIG. 2, which schematically shows a system for checking authorization compatibility between a configuration system and an orchestration system of a computing cluster, according to some embodiments of the present disclosure. The configuration system 201 includes an authorization check agent 207, which is code executed by a server having at least one processor 209, and identifies changes made by a user within a code file 203 or configuration file that defines the configuration of the computing cluster. For example, when a user adds a code line, deletes a code line, or modifies a code line within the code file. The changes may be identified by the authorization check agent 207, for example, by receiving a notification from the configuration system regarding the changes. When the authorization check agent 207 identifies that there has been a change in the file that defines the configuration, the authorization check agent 207 retrieves from the repository 208 the name or identification information of the user and the file affected by the changes made by the user. After the affected file and the name or identification information of the user have been retrieved, the authorization check agent 207 verifies with the orchestration system 202 of the computing cluster whether the changes in the file are authorized for the user according to the authorization access of the orchestration system 202. The authorization check agent 207 receives either an approval response or a rejection response from the orchestration system 202 of the computing cluster and updates the configuration management system according to the received response. If the authorization check agent 207 receives an approval response, the changed file is merged into the master file, and the configuration management system 201 continues the deployment of the master code and configuration to the orchestration system 202 of the computing cluster. If the authorization check agent 207 receives a rejection response, the authorization check agent 207 sends a notification to the configuration management system 201 that the authorization check compatibility has not been approved.

[0053] Next, reference is also made to FIG. 3, which is a flowchart depicting a method for checking authorization compatibility between a configuration management system and an orchestration system of a computing cluster, according to some embodiments of the present disclosure.

[0054] At 301, the user makes changes (e.g., adding a code line, deleting a code line, or modifying a code line) in the code file and / or the configuration file that defines the configuration, and presents the changes in the form of a change request that includes one or more files. The presented change request initiates a change review flow, where the changes in the code file and the configuration file are tested both automatically by running CI / CD tests and by being checked by other users, which reviews the changes to verify that the changes are accurate. At 302, the approval check agent 207 identifies a request to approve the changes presented in at least one file of the computing cluster, for example, by receiving a notification from the configuration management system regarding the presented change request (e.g., the approval check agent identifies the change request). At 303, the approval check agent 207 retrieves the user's identification information for executing the changes from the repository 208 of the configuration management system 201. At 304, the approval check agent sends a query to the orchestration system 202 via the network, and the query requests the right to execute the changes in the files on the orchestration system 202 (and the changes in the files affected by the changes) using the user's identification information. At 305, the approval check agent 207 obtains a rejection response or an approval response to the query from the orchestration system, for example, by receiving a notification informing whether the query requesting to execute the changes in the file according to the retrieved user identification information is approved or rejected. At 306, in response to the approval response, the approval check agent 207 inputs the approval response to the configuration management system 201 to confirm that it is approved to check the approval compatibility (e.g., records the approval in the configuration management system 201).At 307, in response to the rejection response received by the authorization check agent 207 from the orchestration system 202, in order to execute the changes in the file according to the retrieved user identification information, the authorization check agent 207 sends a message to the configuration management system, and the message indicates that it is not approved to check authorization compatibility. The message may be sent, for example, to the user interface to notify that the authorization check compatibility is not approved, or the message can notify what conditions are required for the changes to be approved for the user identification information (such as adding or deleting lines in the code file). According to some embodiments of the present disclosure, the authorization check compatibility is performed during the change review flow of the configuration management system 201.

[0055] According to some embodiments of the present disclosure, the authorization check agent 207 analyzes the set of modified files to detect the specific objects and operations affected by the changes. Moreover, the authorization check agent 207 then accesses the orchestration system and verifies that the retrieved user is authorized to execute the changes in the orchestration system and to apply the objects and operations affected by the executed changes, thereby checking the authorization compatibility with the orchestration system.

[0056] According to some embodiments of the present disclosure, the authorization check agent 207 maps between the user name of the configuration management system 201 and the user name of the orchestration system 202 to check the authorization compatibility between the configuration management system and the orchestration system of the computing cluster. In a simpler case, the user names are directly mapped. Through manual adjustment or, preferably, using an external authentication mechanism (e.g., Lightweight Directory Access Protocol (LDAP), OpenID Connect (OIDC)), the same user name is used in both the configuration management system 201 and the orchestration system 202. In a more complex case, the authorization check agent 207 uses a mapping file to manage the mapping from the user name of the configuration management system 201 to the appropriate principal for access authorization in the orchestration system 202. The mapping file is also maintained within the configuration management system 201 and may undergo a similar review and approval process as the configuration management system 201. The location of the mapping file may depend on the directory organization chosen for the repository 208 (e.g., the mapping file is loaded from the current directory).

[0057] According to some embodiments of the present disclosure, the authorization check agent notifies the configuration management system that the authorization check compatibility has not been verified by notifying the user through the user interface that the change has not been approved. Alternatively, it responds to a request to approve the change (e.g., a change request) with a comment or change request that is consistent with the authorization check compatibility. On the other hand, in response to the approval received from the orchestration system 202 for the user to execute the change, the authorization check agent 207 can apply the change to the computing cluster.

[0058] According to some embodiments of the present disclosure, an example for checking the authorization compatibility between a configuration management system and an orchestration system is a case where the configuration management system is implemented by an operation model for an orchestration system such as a versioning management system and Git and a GitOps workflow, and the orchestration system is Kubernetes. For example, reference is then made to FIG. 4, which schematically shows an exemplary GitOps workflow for checking the authorization compatibility between Git as a configuration management system and Kubernetes as an orchestration system of a computing cluster.

[0059] In 401, the user makes changes such as adding lines, deleting lines, or modifying lines in the code file and / or the configuration file that defines the configuration, and presents the changes in the configuration in the form of a change request (referred to as a pull request in Git system terms) that includes one or more files. In 402, the container is built as a continuous integration (CI) for unit tests and integration tests to verify that the code changes are satisfactory. In 403, the container is registered and stored in a container registry. According to some embodiments of the present disclosure, in 404, the authorization check agent 420 identifies the pull request by receiving a change request notification sent to the authorization check agent 420 by the Git system. The authorization check agent 420 retrieves the identification information of the user who triggered the change and the files affected by the change from the Git repository located in the Git configuration management system 410. Since Kubernetes is a system for managing objects, the objects may be encoded in an appropriate format (e.g., JSON, YAML) and stored in files. The authorization check agent 420 extracts a list of Kubernetes objects affected by the code change (e.g., the name, type, and namespace of the object; the namespace is a way to create a logical separation among users sharing the cluster). The namespace is similar in role to a directory in the file system from the file together with the change type (e.g., line deletion, line creation, line modification) (it is possible to use the same file name in different directories). Optionally, multiple changes of different change types can exist at once, and all are combined into one change set. The authorization check agent 420 determines the Kubernetes user name to be used for access checks, for example, by a 1:1 mapping of the Git system user name to the Kubernetes system user name, or by using a conversion table to convert the Git system user name to the Kubernetes system user name.At 405, the authorization check agent 420 sends a query regarding the right to execute the changes made by the retrieved user to the Kubernetes system. The query may be sent using the Kubernetes Application Programming Interface (API) master (e.g., by using Kubernetes operations such as dry-run, can-i, and user impersonation). At 406, the authorization check agent 420 receives a response from the Kubernetes system, reports the authorization for the pull request, and approves or rejects the pull request. At 407, ultimately, after the authorization check agent 420 receives authorization for authorization check compatibility, the pull request is merged, which means that the changes made by the user are merged into the master code file and configuration, and the GitOps tool pulls the set of changes to the cluster, i.e., the changes are applied to the cluster.

[0060] According to some embodiments of the present disclosure, the methods described herein integrate authorization checks for a target cluster and its policies as part of the testing of changes within the change review flow of a Git configuration management system 410. This enables integrated and consistent access control for Git-based and direct cluster access for operation without replicating user and access management functions within GitOps tools. External systems such as an authorization check agent can request notifications of changed files from Git. The notification information sent by Git includes all the information required by the agent to identify the changes requested by the user. Git can notify external tooling of changes to files stored via a process called a "callback" or "webhook" (e.g., a webhook for a CircleCI tool or a Travis tool). Another example is "GitHub Actions" which can also be used to perform various tooling on a GitHub base. In both modes, the call includes the necessary information about a specific commit such as the commit identifier, the branch being merged, etc. The information is sufficient to access the repository and retrieve the relevant set of changes (or the entire branch / pull request if necessary).

[0061] Upon receiving a notification of changes made within a code file and configuration, the authorization check agent 420 retrieves the affected files and the identifying information of the user who made the changes from the Git repository. With knowledge of the user who made the changes and the files affected by this change, the authorization check agent 420 uses existing Kubernetes functions to verify that the objects included in the changed files may be affected by the user involved in the change. An example of one way to verify that is the command create / apply / delete --server-dry-run --as <username>By using the Kubernetes command line kubectl which has it. Another way to verify it is kubectl auth can-i create <object>--as <username>is to be used.

[0062] Note that the above description is simplified. According to some embodiments of the present disclosure, changes made by a user to a code file may be further analyzed to detect affected objects and operations (for example, adding a file means kubectl create, and deleting a file means kubectl delete. When a file contains multiple object definitions, a fine-grained analysis may be provided by analyzing the output of Git diff to determine which objects in the file are affected). Further, the above description states that all changes apply to the default namespace, but a more accurate analysis within the authorization check agent 420 can determine the namespace for each operation. This may be done by extracting the namespace from the object's metadata. The above test results determine whether changes made by a user are authorized on the cluster. The results are recorded in the pull request (for example, the results may be returned to the configuration management system and updated within the pull request), used to interrupt the pull request, and may be reflected within the user interface (for example, by posting a pull request comment).

[0063] In addition to the above example, in the case of authorization check compatibility between Git and Kubernetes, Git authorization is assigned per repository and is typically grouped into read-only (e.g., public Git access), read-write access (e.g., collaborators), and administrator (e.g., various administrative tasks). However, Kubernetes has several authorization mechanisms, including RBAC (Role-Based Access Control) to ABAC (Attribute-Based Access Control) and webhooks, to enable implementing any access control logic. For example, RBAC rules are associated with a principal (user or service account) and enable the principal to act (e.g., list, read, write, delete) on specific object types (e.g., pods, services, secrets) within a specific namespace (e.g., the namespace assigned to one's team for deployment). In addition to namespace-based RBAC, there are also cluster-wide roles that can grant access rights to objects in all namespaces. Through an example related to the Kubernetes orchestration system, the RBAC mechanism is used as an exemplary access control mechanism, but any mechanism may be used and is applicable.

[0064] According to some embodiments of the present disclosure, the authorization check agent 420 maps between Git users and Kubernetes users to check the authorization compatibility between Git and Kubernetes using a direct 1:1 mapping, or via manual adjustment, or preferably using an external authentication mechanism (e.g., Lightweight Directory Access Protocol (LDAP), OpenID Connect (OIDC)). If the user names are different and there are different user names with different authorization access to each user within Kubernetes, the mapping is done using a mapping file that includes a conversion table that maps the Git user name to the appropriate Kubernetes principal. The mapping file is maintained within Git and may be subject to a similar review and approval flow. The location of the mapping file may depend on the directory layout chosen for the repository (e.g., the mapping file is loaded from the current directory).

[0065] According to some embodiments of the present disclosure, the authorization check agent 420 implemented within Git can operate in different locations and use different runtimes. This may include any suitable mechanism that enables it to receive notifications and respond by executing some user code. It may be a CI / CD system such as Jenkins and CircleCI that enables the execution of shell scripts or container images or both, and it may also be a system composed of functions (i.e., functions-as-a-service (FaaS) that operate on a cloud provider, on-premises, or as part of a code version management system).

[0066] In addition to the above examples, various methods may be used as verification of Kubernetes authentication, including those listed above such as server-dry-run and auth can-i. Additionally, manual impersonation (i.e., extracting access authentication information for a specific user from the cluster) may be used.

[0067] Optionally, all modifications to the Kubernetes cluster are performed by the authorization check agent 420 using a special administrator user, who has authorization access to all types of changes within files in Git as well as all types of objects and operations within Kubernetes. Additionally, manual impersonation may be used as described above to actually apply the modifications to the authorization check agent 420 using a specific username. According to some embodiments of the present disclosure, the identification of the objects affected by the configuration change may depend on the repository configuration and the GitOps tool being used. For example, the user may choose to represent namespaces as directories within the repository and require that each file contain a single configuration object. In such a case, the namespace (i.e., the directory) and the operation (i.e., the change type: file addition or deletion) are apparent from the change set. Alternatively, the authorization check agent 420 should need to parse the files to detect the affected objects and their namespaces (e.g., when each file contains multiple objects or when the tool being used does not separate namespaces by directory).

[0068] According to some embodiments of the present disclosure, in the simplest case, each repository within Git corresponds to a specific cluster within Kubernetes (or a set of similarly configured clusters), either inferred from the external configuration or matched against the access information of the target cluster stored in the configuration of the authorization check agent 420. According to some other embodiments of the present disclosure, the user may use Git branches to represent different operating environments (e.g., test, staging, production).

[0069] According to some embodiments of the present disclosure, the authorization check agent 420 records any verification failures, including illegal object identification information (e.g., type, name, namespace). The same information may be used to update the GitOps tool storage and user interface or to provide direct feedback to the Git pull request in the form of approvals or change requests (if the user is marked as a reviewer / assignee) and pull request comments.

[0070] According to some embodiments of the present disclosure, in the case of an approval check for a change set having changes to a plurality of objects that have been partially rejected (i.e., some of the changes have been approved and some of the changes have been rejected), the approval check agent 420 enables the application of the approved and rejected changes reported to the user interface via the pull request comments sent by the approval check agent 420. In this case, the approval check is performed immediately before or during deployment time, i.e., only after the changes have been approved (e.g., merged into the master branch in Git). Objects that pass the approval check can succeed in deployment at the expense of not preventing invalid configuration changes from being merged into version control even when other objects fail the approval check. The approval check agent 420 can use additional reporting / warning mechanisms to notify when such non-deployable objects as Slack and PagerDuty are detected. Alternatively, the approval check agent 420 reports as a comment on the Git pull request itself or by adding a (deployment) result file. Since the rejected changes may be corrected in the next change set, in this case, some important changes can be applied earlier. In this mode, the cluster state may be different from the truth-telling material stored in Git. While enabled by some GitOps tools, this mode is often used in conjunction with a diff tool to highlight the discrepancies. In some other embodiments of the present disclosure, in the case of an approval check for a change set having changes to a plurality of objects that have been partially rejected, all change sets are rejected.

[0071] According to some embodiments of the present disclosure, in some cases, Git holds object templates and does not hold the final object configurations applied (e.g., they are generated from templates using tools such as Kustomize). In these cases, the authorization check agent 420 needs to initiate any pre - processing steps performed to generate the actual and final object configurations from the templates before verifying the access.

[0072] According to some other embodiments of the present disclosure, the destination cluster is discovered by some external tools such as multi - cluster management tools (e.g., Kubernetes Federation (KubeFed) v2). In these cases, the authorization check agent 420 needs to initiate any pre - processing steps performed to determine the destination cluster and then process the verification. If all destination clusters have the same security configuration, the verification may be performed for one of the clusters.

[0073] According to some embodiments of the present disclosure, although RBAC - based verification is supported across Git artifacts, when it is desirable to prevent direct kubectl access to modify the cluster, it can be implemented in external tools such as requiring client authentication via a Transport Layer Security (TLS) connection, or using dedicated Virtual Private Network (VPN) access for the authorization check agent and blocking all other public access, with a restricted set of Internet Protocol (IP) addresses for an API manager client or a separate verification cluster (including only the API master).

[0074] According to some other embodiments of the present disclosure, a secondary verification loop may be added to enable GitOps flow control to verify that the change set has indeed been checked for access control as part of the pull request verification process in Git. For example, by creating some custom resource definition (CRD). CRD is a way to extend Kubernetes to manage additional object types (e.g., pods, services, deployments) that are not part of the canonical set. CRD defines new object types that can be created and manipulated within Kubernetes. It has control code to manage the lifecycle and actions related to the new type of object. The secondary verification loop may be added by creating some CRD to incorporate the cryptographically signed verification results of the pull request, or by using the audit records / access logs of the API master (using the change set of the pull request identification to correlate audit logs with each other via request headers or the like) to confirm that the tests have indeed been executed against the cluster.

[0075] According to some embodiments of the present disclosure, another example for implementing a configuration management system is by using a specific Kubernetes cluster only for the configuration management system, where all objects are stored, and all changes within the objects may be recorded and tracked. In this case, remote clusters access the specific cluster and apply related changes, and as a result, a group of remote clusters access the specific cluster and apply the related changes to each cluster.

[0076] According to some embodiments of the present disclosure, a computer program product for checking authorization compatibility between a configuration management system and an orchestration system is disclosed. The computer program product includes one or more computer-readable storage media, and program instructions collectively stored on the one or more computer-readable storage media, and the program instructions are Program instructions for identifying a request to approve at least one change in at least one file that defines the configuration of a computing cluster, and Program instructions for retrieving user identification information for executing at least one change from a repository of a configuration management system, and Program instructions for obtaining a rejection response or an approval response received in response to a query supplied to an orchestration system, wherein the query relates to the right to change at least one file using the user identification information, and Program instructions for inputting an approval response to a configuration management system to confirm that it is approved to check authorization compatibility in response to the approval response, and Program instructions for sending a message to a configuration management system in response to a received rejection, wherein the message indicates that it is not approved to check authorization compatibility including.

[0077] Other systems, methods, features, and advantages of the present disclosure will be apparent to or will become apparent to those of ordinary skill in the art upon examination of the following drawings and detailed description of the embodiments for carrying out the invention. All such additional systems, methods, features, and advantages are included within this description, are within the scope of the present disclosure, and are intended to be protected by the accompanying claims.

[0078] The description of the various embodiments of the present invention has been presented for purposes of illustration, but is not intended to be exhaustive or limiting to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein have been chosen to best explain the principles of the embodiments, the practical application, or technical improvements found in the marketplace, or to enable other ordinary skill in the art to understand the embodiments disclosed herein.

[0079] During the term of the patent rights expiring from this application, many related methods and systems will be developed for checking the authorization compatibility between a configuration management system and an orchestration system of a computing cluster, and the scope of the terms "method and system for checking the authorization compatibility between a configuration management system and an orchestration system of a computing cluster" is intended to include all such new technologies a priori.

[0080] As used herein, the term "about" refers to ±10%.

[0081] The terms "comprise", "comprising", "include", "including", "have", and their cognates mean "including but not limited to". This term encompasses the terms "consisting of" and "consisting essentially of".

[0082] The phrase "consisting essentially of" means that a composition or method may include additional components or steps or both, but only if the additional components or steps or both do not substantially modify the basic and novel characteristics of the claimed composition or method.

[0083] As used herein, the singular forms "a", "an", and "the" include plural references unless the context clearly dictates otherwise. For example, the term "a compound" or "at least one compound" may include a plurality of compounds including mixtures thereof.

[0084] The word "exemplary" is used herein to mean "serving as a representative, example, or illustration". Any embodiment described as "exemplary" should not necessarily be construed as preferred or advantageous over other embodiments and / or should not exclude the incorporation of features from other embodiments.

[0085] The term "optionally" is used herein to mean "provided in some embodiments and not provided in other embodiments". Any particular embodiment of the invention may include a plurality of "optional" features as long as such features do not conflict.

[0086] Throughout this application, various embodiments of the invention may be presented in a range format. The description of a range format is for convenience and brevity only and should not be construed as an inflexible limitation on the scope of the invention. Thus, a range description should be considered to have specifically disclosed all the possible sub-ranges as well as the individual numerical values within that range. For example, a range description such as 1 - 6 should be considered to have specifically disclosed sub-ranges such as 1 - 3, 1 - 4, 1 - 5, 2 - 4, 2 - 6, 3 - 6, as well as the individual numbers within that range, for example, 1, 2, 3, 4, 5, and 6. This applies regardless of the breadth of the range.

[0087] Whenever a numerical range is indicated herein, it is meant to include any recited number (fractional or integral) within the indicated range. The phrases "ranging between" a first indicia and a second indicia and "ranging from" a first indicia "to" a second indicia are used interchangeably herein and are intended to include the first and second indicia and all the fractions and integers therebetween.

[0088] It should be understood that some features of the invention that are described in connection with separate embodiments may be provided in combination within a single embodiment. Conversely, various features of the invention that are described in connection with a single embodiment may be provided separately, or in any suitable partial combination, or as suitable in any other described embodiment of the invention. Some features described in connection with various embodiments should not be considered essential features of those embodiments unless the embodiments are inoperative without those elements.

[0089] All publications, patents, and patent applications mentioned in this specification are hereby incorporated by reference in their entirety to the same extent as if each individual publication, patent, or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, any reference citation or identification in this application should not be construed as an admission that such reference is available as prior art to the present invention. To the extent that section headings are used, they should not necessarily be construed as limiting.< / username> < / object> < / username>

Claims

1. A method for checking authorization compatibility between a configuration management system and an orchestration system of a computing cluster, the method comprising, by a processor, identifying a request to approve at least one change in at least one file defining the configuration of the computing cluster; retrieving user identification information for the user to execute the at least one change from a repository of the configuration management system; obtaining a rejection response or an approval response received in response to a query supplied to the orchestration system, the query being related to the right to change the at least one file using the identification information of the user, the obtaining; in response to the approval response, inputting the approval response to the configuration management system to confirm that checking the authorization compatibility is approved; in response to the received rejection, sending a message to the configuration management system, the message indicating that checking the authorization compatibility is not approved, the sending A method comprising.

2. Further comprising, by the processor, analyzing the at least one changed file to detect objects and operations affected by the change; By the processor, accessing the orchestration system to verify that the retrieved user identification information is authorized to execute the change in the orchestration system and to apply the objects and operations affected by the executed change, thereby checking authorization compatibility with the orchestration system. The method according to claim 1, further comprising.

3. Further comprising, by the processor, mapping between a user name of the configuration management system and a user name of the orchestration system of the computing cluster to check authorization compatibility between the configuration management system and the orchestration system of the computing cluster. The method according to claim 1, further comprising.

4. The method according to claim 1, wherein the configuration management system is a versioning management system.

5. The method according to claim 4, wherein the configuration management system is Git.

6. The method according to claim 1, wherein the orchestration system of the computing cluster is Kubernetes.

7. The method according to claim 1, wherein the configuration management system is part of the computing cluster.

8. In response to the received rejection, sending a message to the configuration management system, the following notifying the user via a user interface that the at least one change has not been approved, responding to the request to approve the change with a comment or change request that matches the authorization check compatibility, or adding a result file The method according to claim 1, comprising one of the above.

9. In response to the approval received from the orchestration system of the computing cluster for the user to execute the at least one change, applying the at least one change to the computing cluster The method according to claim 1, further comprising.

10. Identifying the request to approve the at least one change in the at least one file is performed during the change review flow of the configuration management system. The method according to claim 1.

11. Regarding the permission to execute multiple changes in the at least one file, when a query is supplied to the orchestration system and a part of the changes is approved and a part of the changes is rejected, applying the approved part of the changes to the computing cluster and notifying the user via a user interface about the rejected part of the changes. The method according to claim 1.

12. A server having at least one processor for executing a method for checking authorization compatibility between a configuration management system and an orchestration system of a computing cluster, identifying a request to approve at least one change in at least one file defining the configuration of the computing cluster; retrieving the identification information of the user for executing the at least one change from the repository of the configuration management system; Obtaining a rejection response or an approval response received in response to a query supplied to the orchestration system, wherein the query relates to the right to modify the at least one file using the identification information of the user, the obtaining; In response to the approval response, inputting the approval response to the configuration management system to confirm that checking for authorization compatibility is approved; In response to the received rejection, sending a message to the configuration management system, the sending, wherein the message indicates that checking for authorization compatibility is not approved; A server configured to perform the above.

13. Analyzing the at least one modified file to detect objects and operations affected by the modification; Accessing the orchestration system to verify that the retrieved user identification information is authorized to perform the modification within the orchestration system and to apply the objects and operations affected by the performed modification, thereby checking authorization compatibility with the orchestration system; The server according to claim 12, further configured to perform the above.

14. Mapping between the user name of the configuration management system and the user name of the orchestration system of the computing cluster to check authorization compatibility between the configuration management system and the orchestration system of the computing cluster; The server according to claim 12, further configured to perform the above.

15. The server according to claim 12, which executes the method for checking authorization compatibility between the configuration management system and the orchestration system of the computing cluster as part of the configuration management system.

16. The server according to claim 12, which executes the method for checking authorization compatibility between the configuration management system and the orchestration system of the computing cluster as part of a continuous integration and continuous deployment (CICD) system.

17. A server as claimed in claim 12, which, as part of a computing cluster, executes the method for checking authorization compatibility between a configuration management system and an orchestration system of the computing cluster.

18. A computer program for checking authorization compatibility between a configuration management system and an orchestration system, the computer program comprising: program instructions for identifying a request to approve at least one change in at least one file defining a configuration of a computing cluster; program instructions for retrieving identification information of a user for executing the at least one change from a repository of the configuration management system; program instructions for obtaining a rejection response or an approval response received in response to a query supplied to the orchestration system, the query being related to the right of the user's identification information to change the at least one file; program instructions for inputting the approval response to the configuration management system in order to confirm that checking authorization compatibility is approved in response to the approval response; program instructions for sending a message to the configuration management system in response to the received rejection, the message indicating that checking authorization compatibility is not approved A computer program comprising the above.

19. program instructions for analyzing the at least one changed file to detect objects and operations affected by the change; program instructions for accessing the orchestration system to verify that the retrieved user identification information is authorized to execute the change within the orchestration system and to apply the objects and operations affected by the executed change, thereby checking authorization compatibility with respect to the orchestration system The computer program according to claim 18, further comprising the above.

20. Program instructions for mapping between the username of the configuration management system and the username of the orchestration system of the computing cluster in order to check the authorization compatibility between the configuration management system and the orchestration system of the computing cluster The computer program according to claim 18, further comprising

Images