Container-based system for managing user access control to computational resources and method thereof

Abstract

Embodiments of present disclosure provide container-based system (200) and method (600,700) for managing user access control to computational resources in orchestration system (202), configured with system defined roles for use in providing access to computational resource. Container-based system (200) comprises server (204) arranged to be accessed by orchestration system (202). First control system (206) implemented in master node (208) of cluster (210) of orchestration system (202), arranged for receiving access request from user having one of the system defined roles to access computational resources, identifying, based on the system defined role of the user, access request as one of allowable access request providing access to computational resource. When access request identified as pending access request, first control system (206) transmits pending access request to second control system (214) implemented in the server (204). Second control system comprising clustering model (216) to store one or more user group profiles.

Description

[0001] CONTAINER-BASED SYSTEM FOR MANAGING USER ACCESS CONTROL TO COMPUTATIONAL RESOURCES AND METHOD THEREOF

[0002] TECHNICAL FIELD

[0003] The present disclosure relates generally to a field of container orchestration system. More particularly, it relates to managing user access control to one or more computational resources in an orchestration system in the container-based system.

[0004] BACKGROUND

[0005] Containerised applications are those applications which run a container which is a software that packs up a code required for running the application. Such containers include all requirements to run the applications, for example, configuration files, framework, libraries etc. Open source platforms for container orchestration enable developers to easily build and develop containerised applications and services. For example, Kubernetes is an extremely popular open-source container orchestration system for software deployment, scaling, and overall management. Kubernetes is a de-facto standard for large scale software applications. Kubernetes may be adopted for developing and delivering software for 5G Core, Cloud-RAN, Network Management, Licensing and many other applications. Further, Kubernetes provides a framework for managing the containerized applications, allowing to deploy, scale, and automate management of containerized workloads in different cloud-native environments. To keep Kubernetes and workloads / applications in Kubernetes secure, especially in a production environment, security functions should be deployed, configured and maintained regularly based on security practices. One of such security functions in Kubernetes is Role- Based Access Control, RBAC.

[0006] The RBAC helps a user to control access to resources such as memory resources or network resources and actions such as granting or denying access within a Kubernetes cluster. This allows administrators of the Kubernetes to define precise access control policies for users, groups, and service accounts across the Kubernetes cluster and Kubernetes namespaces.

[0007] SUMMARY Understanding various components of the RBAC, including roles (may also be referred to as user role), cluster roles, role bindings, and cluster role bindings, is essential for managing access to Kubernetes resources effectively. The various components are defined below.

[0008] - Roles: A Role is a set of rules that defines a set of permissions within a specific namespace. It is used to define what actions (e.g., grant or restrict access) can be performed on resources like pods or services within the specific namespace.

[0009] - ClusterRoles: ClusterRoles are set of rules that define permissions across the entire Kubernetes cluster, not just a single namespace. The ClusterRoles can be used to govern access (e.g. grant or restrict access) to resources across multiple namespaces.

[0010] - RoleBindings: A RoleBinding connects a specific Role to one or more "subjects" like users, groups, or service accounts, granting them the defined permissions within a specific namespace.

[0011] - ClusterRoleBindings: A ClusterRoleBinding is similar to the RoleBinding but the ClusterRoleBinding connects a ClusterRole with subjects, like users, groups, or service accounts, authorizing them to perform actions across the entire cluster based on defined permissions.

[0012] Further, Kubernetes offers pre-defined user roles for common scenarios:

[0013] - Cluster-admin: The cluster-admin role is a superuser which can perform any action (e.g., read-write- access) on any resource in the cluster. The cluster-admin can be used to grant full control over every resource in the cluster as well as in all the namespaces.

[0014] - Admin: The admin role permits provide administrative control over a specific namespace, said administrative control including creating Roles and RoleBindings within the namespace.

[0015] - Edit: The edit role grants read and write access within a given Kubernetes namespace. The edit role cannot view or modify roles or role bindings.

[0016] - View: The view role provides read-only access within a given namespace. The view role does not allow viewing or modifying of the Roles or the RoleBindings.

[0017] Further a zero trust, ZT, architecture is another popular security approach gaining traction in Information Technology, IT, industry and authorities. The ZT architecture focuses on least privilege per-request access decisions in information systems and services. In the ZT architecture, external (remote) access is restricted. In other words, only trusted, authenticated, and authorized identities can access digital resources using principle of least privilege defined by granular policies. In the ZT architecture, access is granted only a per- session basis. Further, access decisions consider various factors like behavioural attributes and environmental attributes. The behavioural attributes may include, but are not limited to automated subject analytics, device analytics, and measured deviations from observed usage patterns. The environmental attributes may include such factors as requestor network location, time, reported active attacks, etc.

[0018] The rules and attributes are based on requirements of the business process and acceptable level of risk. Resource access and action permission policies can vary based on the sensitivity of the resource. There is existing technology concerning policy decision points, PDP and policy enforcement points, PEP. The PDP / PEP ensure that a subject is authentic and that a request is valid. The subject is allowed to access the resources accordingly. There is an additional component called Policy Information Point, PIP (not clearly defined by current Zero Trust specification but defined e.g. by NISTSP-800- 162), which provides additional behavioural and environmental attributes, helping the PDP / PEP make more informed decisions.

[0019] Though, RBAC is a powerful feature that allows control and management of access to various resources within the Kubernetes cluster, it comes with its own set of challenges. Some of the challenges in Kubernetes RBAC include:

[0020] - Complexity: As the clustergrows, RBAC policies may become quite complex. Managing numerous roles, users, and resources across multiple clusters make RBAC policies difficult to understand and manage manually makes them more complex.

[0021] - Manual configuration of roles: Kubernetes doesn't offer native tools to facilitate automatic granting of roles or updating of role bindings. An administrator may require performing manual setup for each role binding for each new team member, each team, or each new namespace. This can be tedious, error-prone, and time consuming. Updating roles or revoking access may involve even more manual work. Further, misconfigurations may increase the risk of accidentally granting access to unauthorized parties or restricting valid access to authorized parties. - Fine-Grained Control: Definingthe right balance between granting access to users and protecting sensitive resources in Kubernetes can be tricky. It can be difficult to provide enough access to certain users and services to do their jobs in Kubernetes while restricting access to sensitive Kubernetes resources.

[0022] - Role handling: Over time, as resources and users evolve, RBAC roles might become too permissive. Administrators or management may end up adding more permissions to the RBAC roles than are needed or alternatively, too many specific roles for each user or service are created, leading to management headaches. Careful updates and oversight are crucial.

[0023] - Auditing and monitoring: Keeping track of who has access to which resources and services, and monitoring their actions or access rights is challenging, especially in large Kubernetes deployments. Kubernetes doesn't offer any built-in tools for identification of level of access of a user within the cluster, making it even difficult to look up role binding configurations manually.

[0024] - Unauthorized information and disclosure and lateral movement: Broad access to a broad collection of resources may lead to undetected and unauthorized information disclosure and lateral movement over an extended period within the cluster.

[0025] Further, implementing Zero Trust, ZT architecture with RBAC may be challenging, as it may require fine-grained access control and dynamic updates of user roles.

[0026] Thus, there is a need for an improved container-based management of user access to one or more computational resources in an orchestration system, which alleviates at least some of the above-cited problems.

[0027] It is therefore an object of the present disclosure to provide container-based system, first control system, second control system and method for managing user access control to one or more computational resources in an orchestration system to mitigate, alleviate, or eliminate all or at least some of the above-discussed drawbacks of presently known solutions.

[0028] This and other objects are achieved by means of a system, and a method defined in the appended claims. The term exemplary is in the present context to be understood as serving as an instance, example or illustration. According to a first aspect of the present disclosure, a container-based system for managing user access control to one or more computational resources in an orchestration system is provided. The orchestration system is configured with a plurality of system defined roles for use in providing access to the at least one computational resource. The container-based system comprises a server arranged to be accessed by the orchestration system. The container-based system comprises a first control system implemented in a master node of a cluster of the orchestration system. The first control system is being arranged for receiving an access request from a user having one of the system defined roles to access a computational resource. The first control system is further being arranged for identifying, based on the system defined role of the user, the access request as one of an allowable access request providing access to the at least one computational resource. The first control system is further being arranged for identifying, based on the system defined role of the user, the access request as one of a pending access request. When the access request has been identified as a pending access request, the first control system transmits the pending access request to at least one second control system implemented in the server. The at least one second control system comprising at least one clustering model. The at least one clustering model is arranged to store one or more user group profiles. The at least one second control system is arranged for matching the data associated with the system defined role of the user with data of the one or more user group profiles to obtain a matched group profile for the system defined role of the user. The at least one first control system is further arranged for receiving the matched user profile from the at least one second control system and generating an access response for the access request according to the matched user profile.

[0029] Optionally, the the one or more computational resources comprises at least one of: a network, a server, a processor, a memory, storage, an application, a virtual machine, and a service.

[0030] Optionally, the plurality of system defined roles comprises at least one of a default role and a custom role.

[0031] Optionally, the default role comprises at least one of: a cluster admin role, an admin role, an edit role, a view role, a scheduler role, a volume scheduler role and a controller manager role. Optionally, the customer role comprises at least one of: a pod-manager role, a pod-reader role, a cluster-reader role, a pod-monitoring role, a cluster-monitoring role, a deployment manager role.

[0032] Optionally, the server further comprises a database. The database is arranged to store access request log data and the system defined role of the user.

[0033] Optionally, the first control system is further arranged to update the system defined role of the user to an updated role based on the matched user profile and the data associated with the system defined role of the user, when the access request is allowed.

[0034] Optionally, the data of the one or more usergroup profiles comprise at least one of: historical data of the user, how long time the user has been within the orchestration system, number of access requests by the user per day, and a similarity score of the access request.

[0035] Optionally, the matched user profile comprises a user profile matched with the at least one clustering model based on the system defined role.

[0036] Optionally, the first control system is further arranged to reject the access request, when the matched group profile is identified as a profile of non-active users in the orchestration system.

[0037] Optionally, the second control system further comprises a plurality of clustering model, wherein each clustering model comprises one or more user profile groups to be matched with the at least one system defined role of the user from the plurality of system defined role.

[0038] According to a second aspect of the present disclosure, a method for managing user access control to one or more computational resources in an orchestration system is described, the orchestration system is configured with a plurality of system defined roles for use in providing access to the at least one computational resource. The method is implemented in a first control system of the orchestration system. The first control system is implemented in a master node of a cluster, the method comprises receiving, an access request from a user having one of a system defined roles to access a computational resource. The method comprises identifying, the access request as one of: an allowable access request providing access to the at least one computational resource. The method further comprises transmitting a pending request to at least one second control system, when the access request has been identified as a pending access request. The method further comprises receiving a matched user profile from the at least one second control system. The method further comprises generating, an access response for the access request according to the matched user profile.

[0039] Optionally, the one or more computational resources comprises at least one of: a network, a server, a processor, a memory, storage, an application, a virtual machine, and a service.

[0040] Optionally, the plurality of system defined roles comprises at least one of a default role and a custom role.

[0041] Optionally, the default role comprises at least one of: a cluster admin role, an admin role, an edit role and a view role.

[0042] Optionally, the method further comprises updating, the system defined role of the user based on the matched user profile and the data associated with the system defined role of the user, when the access request is allowed.

[0043] Optionally, the method further comprises rejecting the access request, when the matched group profile is identified as a profile of non-active users in the orchestration system.

[0044] Optionally, the matched user profile comprises a user profile matched with the at least one clustering model based on the system defined role.

[0045] According to a third aspect of the present disclosure, there is provided a first control system implemented in a master node of a cluster of the orchestration system. The first control system comprising a controlling circuitry configured to cause receiving, an access request from a user having one of a system defined roles to access a computational resource. The controlling circuitry is further configured to cause identifying, the access request as one of: an allowable access request providing access to the at least one computational resource. The controlling circuitry is further configured to cause transmitting, a pending request to at least one second control system, when the access request has been identified as a pending access request. The controlling circuitry is further configured to cause receiving, a matched user profile from the at least one second control system. The controlling circuitry is further configured to cause generating, by the first control system, an access response for the access request according to the matched user profile. According to a fourth aspect of the present disclosure, there is provided a method for managing user access control to one or more computational resources in an orchestration system, the orchestration system is configured with a plurality of system defined roles for use in providing access to the at least one computational resource. The method is implemented in a second control system of the orchestration system. The method comprises receiving, a pending access request, when the access request has been identified as the pending access request by the at least one first control system. The method further comprises applying, at least one clustering model over data associated with the system defined role of the user, wherein each clustering model stores one or more user group profiles. The method further comprises matching, the data associated with the system defined role of the user with data of the one or more user group profiles to obtain a matched group profile for the system defined role of the user. The method further comprises sending, the matched user profile to the at least one first control system. The at least one first control system generates an access response according to the matched group profile.

[0046] Optionally, the one or more computational resources comprises at least one of: a network, a server, a processor, a memory, storage, an application, a virtual machine, and a service.

[0047] Optionally, the plurality of system defined roles comprises at least one of a default role and a custom role.

[0048] Optionally, the default role comprises at least one of: a cluster admin role, an admin role, an edit role, a view role, a scheduler role, a volume scheduler role and a controller manager role.

[0049] Optionally, the data of the one or more usergroup profiles comprise at least one of: historical data of the user, how long time the user has been within the orchestration system, number of access requests by the user per day, and a similarity score of the access request.

[0050] Accordingto a fifth aspect of the present disclosure, there is provided a second control system implemented in a server of a container-based system, the second control system comprising a controlling circuitry configured to cause receiving, a pending access request, when the access request has been identified as the pending access request by the at least one first control system. The controlling circuitry is further configured to cause applying, at least one clustering model over data associated with the system defined role of the user, wherein each clustering model stores one or more user group profiles. The controlling circuitry is further configured to cause matching, the data associated with the system defined role of the user with data of the one or more user group profiles to obtain a matched group profile for the system defined role of the user. The controlling circuitry is further configured to cause sending, the matched user profile to the at least one first control system, wherein, the at least one first control system generates an access response accordingto the matched group profile.

[0051] According to a sixth aspect of the present disclosure, there is provided a computer program product comprising a non-transitory computer readable medium, having thereon a computer program comprising program instructions. The computer program is loadable into a data processing unit and configured to cause execution of the method according to the first and second aspects when the computer program is run by the data processing unit.

[0052] Some embodiments disclosed herein have one or more of the following advantages: -Provides a technical solution providing behavioural and / or environmental attributes in real time for taking necessary actions such as elevating user roles while granting access to one or more resources.

[0053] - Automates and simplifies manual role management processes, adhering to zero trust principles in the orchestration system.

[0054] - Supports scalability and dynamicity in the orchestration system by observing and accommodating changing conditions and requirements while providing access to resources and thus eliminates a need for constant role modifications.

[0055] - Leverages unsupervised machine learning to create user behavior profiles for taking intelligent and dynamic decisions about user roles and associated access to resourced thereby enabling temporary or permanent role elevations as needed.

[0056] - Provides agent-based architecture in the orchestration system in which local agents

[0057] (first control system) handle real-time user-specific role management close to user process, while a centralized cloud platform (second control system) trains clustering models using big data volumes. - Creation of a three-dimensional data model serves as a foundation for the clustering model which is used for analyzing the user profiles and user roles in the orchestration system.

[0058] - Local agents (first control system) are arranged to take different decisions such as granting access, denying access or elevating user roles based on user roles, allowing controlled user privilege for higher user roles and conditional user privilege elevation (e.g., during system maintenance windows).

[0059] - Enhancing security and risk mitigation by dynamically taking the decisions of granting access, denying access or elevating user roles based on contextual and user behavior factors such as historical data of the user, how long time the user has been within the orchestration system, number of access requests by the user per day, and a similarity score of the access request and changes in the monitored environment.

[0060] Other advantages may be readily apparent to one having skill in the art. Certain embodiments may have none, some, or all of the recited advantages.

[0061] BRIEF DESCRIPTION OF THE DRAWINGS

[0062] The foregoing will be apparent from the following more particular description of the example embodiments, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the example embodiments.

[0063] FIG. 1 discloses a wireless communication system according to some examples;

[0064] FIG. 2 is a schematic block diagram illustrating an example container-based system for managing user access control to one or more computational resources in an orchestration system;

[0065] FIG. 3 is a schematic block diagram illustrating an example first control system arranged in the container-based system;

[0066] FIG. 4 is a schematic block diagram illustrating an example second control system arranged in the container-based system; FIG. 5 is a schematic block diagram illustrating an example implementation of the containerbased system for managing user access control to one or more computational resources in an orchestration system;

[0067] FIG. 6 is a flowchart illustrating example steps for a method performed through the first control system for managing user access control to one or more computational resources in an orchestration system;

[0068] FIG. 7 is a flowchart illustrating example steps for a method performed through the second control system for managing user access control to one or more computational resources in an orchestration system;

[0069] FIG. 8 illustrates an example three-dimensional data model aarranged in the container-based system;

[0070] FIG. 9 illustrates an example flowchart depicting functionality of the second control system;

[0071] FIG. 10 illustrates an example flowchart depicting functionality of the first control system; and

[0072] FIG. 11 discloses an example computing environment.

[0073] DETAILED DESCRIPTION

[0074] Aspects of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings. The systems and methods disclosed herein can, however, be realized in many different forms and should not be construed as being limited to the aspects set forth herein. Like numbers in the drawings refer to like elements throughout.

[0075] The terminology used herein is for the purpose of describing particular aspects of the disclosure only and is not intended to limit the invention. It should be emphasized that the term "comprises / comprising" when used in this specification is taken to specify the presence of stated features, integers, steps, or components, but does not preclude the presence or addition of one or more other features, integers, steps, components, or groups thereof. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0076] Embodiments of the present disclosure will be described and exemplified more fully hereinafter with reference to the accompanying drawings. The solutions disclosed herein can, however, be realized in many different forms and should not be construed as being limited to the embodiments set forth herein.

[0077] It will be appreciated that when the present disclosure is described in terms of a system and a method, it may also be embodied in one or more processors and one or more memories coupled to the one or more processors, wherein the one or more memories store one or more programs that perform the steps, services and functions disclosed herein when executed by the one or more processors.

[0078] FIG. 1 discloses an example wireless communication system 100. Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the examples disclosed herein are described in related to a wireless communication system / wireless network, such as the example wireless communication system 100 described in FIG. 1.

[0079] The wireless communication system 100 may comprise and / or interface with any type of communication, telecommunication, data, cellular, and / or radio network or other similar type of system. The wireless communication system 100 may be configured to operate according to specific standards or other types of predefined rules of procedures. Thus, the wireless communication system 100 may implement communication standards, such as, but are not limited to, global system for mobile communications, GSM, universal mobile telecommunications system, UMTS, long term evolution, LTE, and / or other suitable 2G, 3G, 4G, or 5G standards, wireless local area network, WLAN, standards such as, IEEE 802.11 standards, and / or any other appropriate wireless communication standards, such as, worldwide interoperability for microwave access, WiMax, Bluetooth, Z-Wave and / or ZigBee standards.

[0080] For simplicity, as depicted in Fig. 1, the wireless communication system 100 comprises a container-based system 200, a network node 104, and a network 106. The container-based system 100 and the network node 104 operate together in order to provide wireless connections in the wireless communication system 100. The network 106 may comprise one or more backhaul networks, core networks, IP networks, public switched telephone networks, PSTNs, packet data networks, optical networks, wide-area networks, WANs, local area networks, LANs, wireless local area networks, WLANs, wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices (for example, wireless devices and network node).

[0081] The network node 104 may refer to equipment capable, configured, arranged, and / or operable to communicate directly or indirectly with the container-based system 200 and / or with other network nodes or equipment in the wireless communication system 100 to enable and / or provide wireless access to the container-based computer system 200 and / or to perform other functions (for example, administration) in the wireless communication system 100. Examples of the network node 104 may include, but are not limited to, access points, APs (for example, radio access points), base stations, BSs (for example, radio base stations, nodeBs, evolved NodeBs, eNBs, new radio, NR, nodes (gNBs), or the like). The BSs may be categorized based on an amount of coverage the BSs provide (or, stated different, their transmit power level) and may then also be referred to as femto BSs, pico BSs, micro BSs, macro BSs. The BS may be a relay node or a relay donor node controlling a relay.

[0082] The container-based computer system 200 may refer to a device capable, configured, arranged and / or operable to communicate wirelessly with the network node 104 and / or other wireless devices.

[0083] In some examples, the container-based system 200 may include one or more of: computing devices, wireless devices, ultra-low power wireless devices, Internet of Things, loT, devices, and so on.

[0084] Examples of the computing devices may include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over Internet Protocol, IP, VoIP, phone, a wireless local loop phone, a desktop computer, a personal digital assistant, PDA, a wireless camera, a gaming console or device, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment, LEE, a laptop-mounted equipment, LME, a smart device, a wireless customer-premise equipment, CPE, a vehicle- mounted wireless terminal device, and so on.

[0085] It should be understood that the container-based system 200 may not be limited to the above-described wireless devices. The container-based system 200 may be extended to other wireless devices of different classes or categories providing different services while supporting, for example, Enhanced Mobile Broadband, eMBB, massive Machine-Type Communication, MTC, Ultra-Reliable Low Latency Communication, URLLC, Time Sensitive Networking, TSN, or the like.

[0086] In the wireless communication system 100, the network node 104 and the container-based system 200 are connected through 3GPP 5G core network where specific network services and operations are provided through software components called network functions (NFs). The wireless communication system 100 hosts large scale applications.

[0087] Implementing Zero Trust, ZT architecture with Role-Based Access Control, RBAC can be challenging, as it may require fine-grained access control and dynamic updates. In practical terms there is lack of technical solutions for conveying on-line, timely behavioural and environmental attributes for achieving necessary dynamicity while granting access to one or more resources, which are more in scope of Policy Base Access Control, PBAC.

[0088] Thus, the present disclosure enables the wireless communication network 100, the network node 104, and the container-based system 200 to manage user access control to one or more computational resources in an orchestration system wherein the orchestration system is configured with a plurality of system defined roles for use in providing access to the at least one computational resource.

[0089] FIG. 2 is a schematic block diagram illustrating an example container-based system 200 for managing user access control to one or more computational resources in an orchestration system 202. The orchestration system 202 is configured with a plurality of system defined roles for use in providing access to at least one computational resource. The container-based system 200 comprising a server 204. The server 204 is arranged to be accessed by the orchestration system 202.

[0090] The container-based system 200 further comprising a first control system 206. The first control system 206 is implemented in a master node 208 of a cluster 210 of the orchestration system 202. The first control system 206 is being arranged for receiving an access request from a user 212 having one of the system defined roles to access a computational resource. The first control system 206 is further being arranged for identifying, the access request as an allowable access request providing access to the at least one computational resource. The first control system 206 is further being arranged for identifying the access request as one of a pending request based on the system defined role of the user. When the first control system 206 identifies the access request as the pending request, the first control system 206 transmits the pending access request to at least one second control system 214.

[0091] The second control system 214 is being implemented in the server 204. In an example, the server 204 can be a cloud server. The at least one second control system 214 comprises at least one clustering model 216. The at least one clustering model 216 is arranged to store one or more user group profiles. The at least one second control system 214 is arranged for matching the data associated with the system defined role of the user with data of the one or more user group profiles to obtain a matched group profile for the system defined role of the user.

[0092] The first control system 206 is further arranged to receive the matched user profile from the at least one second control system 214. The first control system 206 is further arranged to generate an access response responding to the access request according to the matched user profile.

[0093] Optionally, the one or more computational resources comprises at least one of: a network, a server, a processor, a memory, storage, an application, a virtual machine, and a service.

[0094] Optionally, the plurality of system defined roles comprises at least one of a default role and a custom role.

[0095] Optionally, the default role comprises at least one of: a cluster admin role, an admin role, an edit role, a view role, a scheduler role, a volume scheduler role and a controller manager role. Examples of the default role in Kubernetes may include a cluster-admin role (super-user role), an admin role, an edit role, a view role, a kube-scheduler role, a volume-scheduler role, a kube-controller-manager role.

[0096] Optionally, the customer role comprises at least one of: a pod-manager role, a pod-reader role, a cluster-reader role, a pod-monitoring role, a cluster-monitoring role, a deployment manager role. Optionally, the server 204 further comprises a database 218, wherein the database 218 is arranged to: store access request log data and the system defined role of the user. In an example, the user profile data, the system defined role of the user, the access response from the first control system 206, timestamp of the access request are sent to the server 204 which can be stored in the database 218.

[0097] In an example, the system defined role of the user provides the user e.g. read, write, view or super user access (cluster-admin) depending on a role of the user to which the user is associated with via role binding.

[0098] Further, the access may comprise an access to execute the access request and access to manipulate the at least one computational resource. Examples of the access may include lists of selected commands and resources that the user is or is not allowed to execute. In the default roles, Kubernetes has defined the allowed commands (also may referred as allowable access request) and the at least one computational resource in a default fashion. Further, as the system defined role of the user may comprise the custom role, an administration must define what commands and resources can be accessed by a certain system defined role of the user.

[0099] Optionally, the first control system (206) is further arranged to update the system defined role of the user to an updated role based on the matched user profile and the data associated with the system defined role of the user, when the access request is allowed.

[0100] In an example, in Kubernetes, the system defined role of the user can be updated to the updated role by composing a role and a role binding in a hierarchical manner. Optionally, the data of the one or more user group profiles comprise at least one of: historical data of the user, how long time the user has been within the orchestration system, number of access requests by the user per day, and a similarity score of the access request.

[0101] Optionally, the matched user profile comprises a user profile matched with the at least one clustering model based on the system defined role.

[0102] Optionally, the first control system is further arranged to reject the access request, when the matched group profile is identified as a profile of non-active orchestration system 202. Optionally, the second control system is further comprising a plurality of clustering model, wherein each clustering model comprises one or more user profile groups to be matched with the at least one system defined role of the user from the plurality of system defined role.

[0103] In FIG. 3, a block diagram illustrates example designs of the first control system 206.. The first control system 206 may be implemented in the master node 208 of the cluster 210 of the orchestration system 202 (as shown in FIG. 2 above). As shown in FIG. 3, the first control system 206 comprises one or more modules. The one or more modules may comprise a memory 302, a processor 304, a controlling circuitry 306, a transceiver 308, and a ML module 310. The controlling circuitry 306, may be adapted to control the other modules.

[0104] The memory 302, the processor 304, the transceiver 308, and the ML module 310 as well as the controlling circuitry 306, may be operatively connected to each other.

[0105] The controlling circuitry 306 may be adapted to control the steps as executed by the first control system 206. For example, the controlling circuitry 306 may be adapted to receive the access request from the user 212 having one of the system defined roles to access a computational resource, identify the access request as one of an allowable access request or a pending access request, receive the matched user profile from the at least one second control system 214, generating an access response for the access request according to the matched user profile (as described above in conjunction with the container-based system 200 and FIG. 2).

[0106] The memory 302 may be adapted to store the access request sent from the userand historical data of the user. In an example, the memory 302 may be adapted to store the clustering model 216 which is provisioned from the second control system 204.

[0107] The processor 304 may be adapted to identify, the access request as one of the allowable access request, providing access to the at least one computational resource. The processor 304 may be adapted to identify, the access request as the pending access request, and transmit the pending access request to at least one second control system 214 implemented in the server 204.

[0108] The transceiver 308 may be adapted to collect the access request sent from the user and historical data of the user. The ML module 310 may be adapted to create clustering model based on the historical data of the user and access request log data.

[0109] In FIG. 4, a block diagram illustrates example designs of the second control system 214. The second control system 214 comprises one or more modules. The second control system 214 implemented in the server 204. As shown in FIG. 4, the second control system 214 comprises one or more modules. The one or more modules may comprise a memory 402, a processor 404, a controlling circuitry 406, a transceiver 408, and a ML module 410. The controlling circuitry 306, may be adapted to control the other modules.

[0110] The memory 402, the processor 404, the transceiver 408, and the ML module 410 as well as the controlling circuitry 406, may be operatively connected to each other.

[0111] The controlling circuitry 406 may be adapted to control the steps as executed by the second control system 214. For example, the controlling circuitry 406 may be adapted to receive the pending access request, apply the at least one clustering model over data associated with the system defined role of the user, match the data associated with the system defined role of the user with data of the one or more user group profiles to obtain a matched group profile for the system defined role of the user, send the matched user profile to the at least one first control system, (as described above in conjunction with the container-based system 200 and FIG. 2).

[0112] The memory 302 may be adapted to store the access request sent from the first control system 206 and one or more user profile of the user. In an example, the memory 302 may be adapted to store one or more clustering model use for training data model.

[0113] The processor 304 may be adapted to apply the at least one clustering model over data associated with the system defined role of the user, match the data associated with the system defined role of the user with data of the one or more user group profiles to obtain a matched group profile for the system defined role of the user.

[0114] The transceiver 308 may be adapted to collect the access request log data and historical data of the user, sent from the first control system.

[0115] The ML module 310 may be adapted to create one or more clustering model based on the historical data of the user and access request log data. FIG. 5 is a schematic block diagram illustrating an example container-based system 5000 for managing user access control to one or more computational resources in an orchestration system 500. The container-based system 5000 is similar to the container-based system 200 as discussed above in FIG. 2.

[0116] In an example, the orchestration system 500 may comprise a Kubernetes orchestration system or Kubernetes. In an example, the orchestration system may have a plurality of clusters 514, as shown in FIG. 5. The container-based system 5000 comprises a first control system 504 (shown as local agent 504 in FIG. 5) being implemented in a master node 506 of a cluster 514 from the plurality of clusters 514. In an example, the first control system is referred as local agent 504 as shown in FIG.5. A server 516 is arranged to be accessed by the orchestration system. In an example, the server is referred as a cloud server 516 as shown in FIG.5.

[0117] The local agent 504 monitors the access request (also may referred as user commands) like a proxy between the user 502 and the master node 506 of the orchestration system that implements role-based access control. In an example, if the access request "apply_f FILENAME" is entered by the user 502, the access request may have a command part "apply" which may refer to the role and "f filename" may refer to a target resource to which the user 502 requests for an access. The local agent 504 may take three different actions based on the system defined role of the user and based on analysis of user behaviour. The first action depicts a scenario (B): If the user has sufficient system defined role for the access request to access of the at least one computational resource, the local agent 504 does not interfere with the access request and only logs the access request and streams the log to the second control system or cloud agent 508, as shown in FIG. 5. The second and the third action are triggered if the system defined role of the user is not sufficient for using the access request or for accessing the at least one computational resource. If the system defined role of the user does not have sufficient privileges, the local agent 504 utilizes clustering model 512, that is provisioned by the cloud agent 508, to define in which user group profile of the user belongs to. Based on the user group profile and the configuration of the local agent 504, the local agent 504 may take a decision to elevate privileges to a higher system defined role (A.l) either temporarily or permanently or deny the access request (A.2). The local agent can be configured, by the admin human user, to enable user role escalation based on target user profile group, based on the evidence of historical temporary user group profile, and if the local agent 504 is allowed to escalate the system defined role of the user temporarily or permanently, which is described in detail later in FIG. 9 and FIG. 10.

[0118] FIG. 6 is a flowchart illustrating example steps for a method 600 performed through the first control system 206 for managing the user access control to one or more computational resources in the orchestration system 202. The orchestration system 202 is configured with the plurality of system defined roles for use in providing access to the at least one computational resource.

[0119] The order in which the method 600 is described is not intended to be construed as a limitation, and any number of the described method blocks may be combined in any order to implement the method 600 or alternate methods. Additionally, individual blocks may be deleted from the method 600 without departing from the scope of the invention as defined in the claims.

[0120] At step 602, the method 600 comprises receiving, the access request from the user having one of the system defined roles to access the computational resource.

[0121] At step 604, the method 600 comprises identifying, the access request as one of the allowable access request providing access to the at least one computational resource.

[0122] At step 606, the method 600 comprises transmitting, the pending request to the at least one second control system 214, when the access request has been identified as a pending access request.

[0123] At step 608, the method 600 receives the matched user profile from the at least one second control system 214.

[0124] At step 610, the method 600 generates the access response for the access request according to the matched user profile.

[0125] Optionally, the one or more computational resources comprises at least one of: a network, network bandwidth, a server, a processor, a memory, storage, an application, a virtual machine, and a service. Optionally, the plurality of system defined roles comprises at least one of a default role and a custom role.

[0126] Optionally, the default role comprises at least one of: a cluster admin role, an admin role, an edit role and a view role.

[0127] Optionally, the method 600 further comprises updating, the system defined role of the user based on the matched user profile and the data associated with the system defined role of the user, when the access request is allowed.

[0128] Optionally, the method 600 further comprises rejecting the access request, when the matched group profile is identified as a profile of non-active orchestration system.

[0129] Optionally, the matched user profile comprises a user profile matched with the at least one clustering model based on the system defined role.

[0130] Optionally, additional details of the method 600 are similar to the details of the method 300 and hence are not repeated for the sake of brevity.

[0131] FIG. 7 is a flowchart illustrating example steps for a method 700 performed through the second control system 206 for managing user access control to one or more computational resources in an orchestration system 202.

[0132] The order in which the method 700 is described is not intended to be construed as a limitation, and any number of the described method blocks may be combined in any order to implement the method 700 or alternate methods. Additionally, individual blocks may be deleted from the method 700.

[0133] At step 702, the method 700 comprises receiving, the pending access request, when the access request has been identified as the pending access request by the at least one first control system 206.

[0134] At step 704, the method 700 comprises applying the at least one clustering model 216 over data associated with the system defined role of the user. Each clustering model 216 stores one or more user group profiles. At step 706, the method 700 comprises matching, the data associated with the system defined role of the user with data of the one or more user group profiles to obtain a matched group profile for the system defined role of the user.

[0135] At step 708, the method 700 sends the matched user profile to the at least one first control system 206. The at least one first control system (206) generates the access response according to the matched group profile.

[0136] Optionally, the one or more computational resources comprises at least one of: a network, network bandwidth, a server, a processor, a memory, storage, an application, a virtual machine, and a service.

[0137] Optionally, the plurality of system defined roles comprises at least one of a default role and a custom role.

[0138] Optionally, the default role comprises at least one of: a cluster admin role, an admin role, an edit role and a view role.

[0139] Optionally, the data of the one or more usergroup profiles comprise at least one of: historical data of the user, how long time the user has been within the orchestration system, number of access requests by the user per day, and a similarity score of the access request.

[0140] Optionally, additional details of the method 700 are similar to the details of the method 300 and hence are not repeated for the sake of brevity.

[0141] FIG. 8 shows an example three-dimensional data model 800 to define user group profiles in the container-based computer system 200. In an example, as shown in FIG. 8, the three- dimensional data model 800 is designed to define three different user profile groups. The three different user profile groups are named as, active group, regular group and passive group. In the three-dimensional data model 800, axes are composed from the data of one or more user group profiles. The data of one or more group profiles may include and not limited to how long time the user has been within the orchestration system, number of access requests by the user per day, and a similarity score of the access request. In an example, as shown in FIG. 8, there are 3 axes which include Time active, Activity (commands per day) and Command similarity score. Based on the three-dimensional data model 800, the clustering model 216 (as discussed in FIG. 2) is generated for each of the system defined role of the user (alternatively may referred as user role. In an example scenario, Kubernetes has default user roles (system defined role of the user) as cluster admin role, admin role, edit role, and view role. In this example scenario, four different clustering models are created to depict various user profiles per system defined role of the user / user role. However, the proposed implementations are not limited to Kubernetes. Further, the proposed implementations are not limited to use of four roles. Instead, the number of roles may be increased or decreased. In the three-dimensional model 800, the users are assigned in this three-dimensional space based on user behavior. The user behavior can be measured from the access request logs. In an example, the user behavior may include but is not limited to historical data of the user, how long time the user has been within the orchestration system, number of access requests by the user per day, and a similarity score of the access request.

[0142] In an example, as shown in FIG. 8, the time active is measured by considering how long a user has been active within the orchestration system 202 (not shown in FIG. 8). Similarly, Activity (access request per day) are measured by taking an average number of the access requests entered or requested by the user. Further, Command similarity score is measured by calculating distribution of the access request (also may referred as command distribution) for the user and scoring a point when the access request is found in the distribution of the access request for the respective system defined role of the user. In an example, as depicted in FIG. 5, if the user 502 has entered the access request as, “kubectl apply -f filename", and the access request is found in the distribution of the access request for the system defined role of the user (user role) with a high frequency, a point for the user may be scored. The frequency in the distribution of the access request for the user role is a configurable parameter and an acceptance to score a point is performed, if the access request entered by the user is one of the 95% of the access request (also may referred as commands) in user role command distribution. In an example, a clustering model can be created in which columns are defined by the three dimensions and each row depicts measurement value for each user. The three user profile groups can be automatically deducted by assigning label 'active' (users with active user behavior) to the group that is the furthest from the origo, label 'passive' (users with passive user behavior) can be assigned to the group that is the closest from the origo (point at which the axes of a coordinate system intersect), and the last group will be assigned with a label of 'regular' (users with passive user behavior). In other words, the user profiles can be found in one at least one of the active group, the passive group and the regular group. The active group 802 comprises the user profile group that is furthest from the origo. The passive group 804 comprises the user profile group that is closest to the origo. The regular group 806 comprises the user profile group that is closest to the origo.

[0143] FIG. 9 illustrates an example flowchart depicting functionality of the second control system 214. Now, FIG. 9 demonstrates how the second control system 214 employs the three- dimensional model (as discussed in FIG. 8) to fit a clustering model that is furthermore provisioned to the first control system. In an example, the second control system 214 may refer to the cloud agent and the first control system may refer to the local agent.

[0144] As shown in FIG. 9, at step 902, the second control system 214 (as shown in FIG. 2), create one or more user group profiles based on the system defined role of the user. The one or more user group profiles are created using the request access log data entered by the user, which are collected by the first control system (local agent) and stored by the second control system. The number of user group profiles (hereinafter referred to as grouped data) is equivalent to the number of the system defined role of the user. In other words, the second control system may fit or train one cluster model per the system defined role of the user. After the data has been grouped per the system defined role of the user, at step 904, the second control system 214 checks if there are the system defined role of the user (user roles) without the matched group profile (e.g. matching clustering model). If there are the system defined role of the user without matching clustering model, at step 906 and 908, the second control system 214 may begin the model training by creating access request distribution (also may referred as command distribution) for the system defined role of the user that is furthermore used in scoring the user's access request similarity score as depicted in the relation to FIG. 8.

[0145] At step 910, the second control system 214 checks if there is any user group profile without user's access request similarity score (also may referred as command similarity score). If the second control system 214 identifies a user without the similarity score, at step 912, the second control system 214 creates the request access distribution (e.g. command distribution) for user. At step 914, the second control system 214 calculates the similarity score for the access request (also may referred as command similarity score). In addition to the command similarity score, the second control system 214 also measures the time active and activity (commands per day) values for each user and the values are further used to fit the clustering model 216 (as shown in FIG. 2) at step 918. In an example, the clustering model 216 is a K-means clustering model, in which columns are Time active, Activity, Command similarity score, and rows are the users. The similarity score of the access request is calculated by taking the request access distribution (e.g. command distribution) for the user. After the clustering model is fitted, at step 920, the second control system 214 stores the clustering model. At step 922, the second control system 214 provisions the clustering models to the first control system 206.

[0146] FIG. 10 illustrates an example flowchart depicting functionality of the first control system 206 (shown in FIG. 2). In an example, the first control system 206 is the local agent 504 (as shown in FIG. 5). Now, FIG. 10 demonstrates how the first control system 206 applies the clustering model 216 (as shown in FIG. 2) model to generate the access response for the access request according to the matched user profile. In other words, the local agents take actions of elevating user privileges, either temporarily or permanently, or denying the access request entered by the user.

[0147] The first control system 206 operates in real-time and uses pre-trained clustering model 216 in decision making which is an advantage of the proposed container-based computer system 200 and corresponding methods 600, 700. As shown in FIG. 10, at step 1002, the first control system 206 receives the access request (also may referred as command) from the user which may indicate that either the command or the computational resource is not covered by the privileges of the system defined roles of the user. If the system defined role enables utilization of the command and the resource, then the first control system 206 only logs and sends the logged access request (also may referred as logged command) information to the second control system 214 (as shown in FIG.2). In an example, the second control system 214 may implemented in a cloud server. After receiving the access request from the user, at step 1004, the first control system 206 finds the user role of the user. In an example, the first control system 206 receives the access request to obtain a higher user role privilege. At step 1006, the first control system 206 applies the clustering model 216 that has been trained with the data of the corresponding system defined role of the user. At step 1008, the first control system 206 analyzes result of the clustering model 216 to define the user group profile of the user, while applying the clustering mode 216.

[0148] During the analysis, the first control system 206 utilizes the historical log data of the user in definition of the user's Time Active, the Activity (commands per day), and the command similarity Score. Based on the historical log data of the user, the first control system 206 may allocate the user in the three-dimensional data model. Then the first control system 206 may define the matched profile group for the system defined role of the user. In other words, the first control system 206 may define the matched profile group to which the user belongs to. After the first control system 206 has defined in which matched profile group (also may referred as user profile group) the user belongs to, at step 1110, the first control system 206 checks if the user belongs to the active group or not. If the first control system 206 identifies that the user doesn't belong to the active group, at step 1112, the first control system 206 denies the access request, which is in line with the user role definition. However, if the user belongs to the active group, at step 1114, the first control system 206 checks if the user has previous history of elevated user privilege utilization.

[0149] In an example, the previous history may be due to temporarily elevated user rights or other evidence of user's higher user privileges. Based on such evidence, at step 1116 and step 1118, the first control system 206 may apply the elevated and corresponding new clustering model to analyze in which elevated user group profile the user would belong to. At step 1120, if the first control system 206 identifies that user belongs to the active or the regular elevated user group profile, then the first control system 206 can elevate user privileges to the higher user role either temporarily or permanently at step 1122 and 1128. If the first control system 206 identifies that the user has not elevated privileges, at step 1124, the first control system 206 checks if the user has permission to elevate privileges. In an example, the threshold if the user is required to be regular or active user is defined by cluster admin and can be defined for each user role. For example, if the user has the system defined role as view user role with limited user privileges, then the user privileges can be elevated if the user belongs to the regular user group in elevated the system defined role of the user (user role) of edit (using Kubernetes examples). If the user does not have previous history in elevated user privileges, then the first control system 206 can be configured to either elevate or not the user privileges. In some examples, if the user would require higher user privileges during a system maintenance window, then the first control system 206 may permit higher user privileges with lower requirements to enable the execution of the maintenance related actions.

[0150] Further, if the first control system 206 is configured to elevate user privileges temporarily, the system defined role of the user is elevated only during the session. At step 1126, the - first control system 206 may deny the access request if there is no permission to elevate privileges. If the first control system 206 is configured to elevate user privileges permanently, the system defined role of the user (user role) is elevated permanently by assigning the higher user role for the user. This is aligned with zero-trust principles and automates generally manual and laborious user role management processes.

[0151] FIG. 11 illustrates an example-computing environment 1100 implementing a container-based system 200, and a method 600, 700 as shown in FIGS. 2, 6 and 7 for managing user access control to one or more computational resources in an orchestration system 202. As depicted in FIG. 11, the computing environment 1100 comprises at least one data processing module 1106 that is equipped with a control module 1102 and an Arithmetic Logic Unit (ALU) 1104, a plurality of networking devices 1108 and a plurality Input output, I / O devices 1110, a memory 1112, a storage 1114. The data processing module 1106 may be responsible for implementing the container-based system 200, and a method 600, 700 as shown in FIGS. 2, 6 and 7 respectively. For example, the data processing module 1106 in some embodiments be equivalent to the controlling circuitry of the platform described above in conjunction with FIGS. 2, 6 and 7. The data processing module 1106 is capable of executing software instructions stored in memory 1112. The data processing module 1106 receives commands from the control module 1102 in order to perform its processing. Further, any logical and arithmetic operations involved in the execution of the instructions are computed with the help of the ALU 1104.

[0152] The computer program is loadable into the data processing module 1106, which may, for example, be comprised in an electronic apparatus (such as the platform). When loaded into the data processing module 1106, the computer program may be stored in the memory 1112 associated with or comprised in the data processing module 1106. According to some embodiments, the computer program may, when loaded into and run by the data processing module 1106, cause execution of method steps according to, for example, any of the methods illustrated in FIGS. 2, 6 and 7, or otherwise described herein. The overall computing environment 1100 may be composed of multiple homogeneous and / or heterogeneous cores, multiple CPUs of different kinds, special media and other accelerators. Further, the plurality of data processing modules 606 may be located on a single chip or over multiple chips. The algorithm comprising of instructions and codes required for the implementation are stored in either the memory 1112 or the storage 1114 or both. At the time of execution, the instructions may be fetched from the corresponding memory 612 and / or storage 1114, and executed by the data processing module 1106.

[0153] In case of any hardware implementations various networking devices 608 or external I / O devices 1110 may be connected to the computing environment to support the implementation through the networking devices 1108 and the I / O devices 1110.

[0154] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the elements. The elements shown in FIG. 11 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.

Claims

CLAIMS1. A container-based system (200) for managing user access control to one or more computational resources in an orchestration system (202) wherein the orchestration system (202) is configured with a plurality of system defined roles for use in providing access to the at least one computational resource; the container-based system (200) further comprising: a server (204) arranged to be accessed by the orchestration system (202), a first control system (206) implemented in a master node (208) of a cluster (210) of the orchestration system (202), said first control system (206) being arranged for: receiving an access request from a user (212) having one of the system defined roles to access a computational resource; identifying, based on the system defined role of the user, the access request as one of: an allowable access request providing access to the at least one computational resource, and a pending access request, when the access request has been identified as a pending access request, transmitting the pending access request to at least one second control system (214) implemented in the server (204); wherein the at least one second control system (214) comprising: at least one clustering model (216), wherein the at least one clustering model (216) is arranged to store one or more user group profiles; and wherein the at least one second control system (214) is arranged for: matchingthe data associated with the system defined role of the user with data of the one or more user group profiles to obtain a matched group profile for the system defined role of the user; wherein the at least one first control system (206) is arranged for:receiving the matched user profile from the at least one second control system (214); and generating an access response for the access request according to the matched user profile.

2. The container-based system (200) according to any of the preceding claims, wherein the one or more computational resources comprises at least one of: a network, a server, a processor, a memory, storage, an application, a virtual machine, and a service.

3. The container-based system (200) according to any of the preceding claims, wherein the plurality of system defined roles comprises at least one of a default role and a custom role.

4. The container-based system (200) according to claim 3, wherein the default role comprises at least one of: a cluster admin role, an admin role, an edit role, a view role, a scheduler role, a volume scheduler role and a controller manager role.

5. The container-based system (200) according to any of the preceding claims, wherein the server (204) further comprises a database (218), wherein the database (218) is arranged to: store access request log data and the system defined role of the user.

6. The container-based system (200) according to any of the preceding claims, wherein the first control system (206) is further arranged to: update the system defined role of the user to an updated role based on the matched user profile and the data associated with the system defined role of the user, when the access request is allowed.

7. The container-based system (200) according to any of the preceding claims, wherein the data of the one or more user group profiles comprise at least one of: historical data of the user, how long time the user has been within the orchestration system, number of access requests by the user per day, and a similarity score of the access request.

9. The container-based system (200) according to any of the preceding claims, wherein the matched user profile comprises a user profile matched with the at least one clustering model (216) based on the system defined role.

8. The container-based system (200) according to any of the preceding claims, wherein the first control system is further arranged to: reject the access request, when the matched group profile is identified as a profile of non-active users in the orchestration system (202).

9. The container-based system (200) according to any of the preceding claims, wherein the second control system further comprises: a plurality of clustering model (216), wherein each clustering model (216) comprises one or more user profile groups to be matched with the at least one system defined role of the user from the plurality of system defined role.

10. A method (600) for managing user access control to one or more computational resources in an orchestration system (202), wherein the orchestration system (202) is configured with a plurality of system defined roles for use in providing access to the at least one computational resource, wherein the method (600) is implemented in a first control system (206) of the orchestration system (202), and wherein the first control system (206) is implemented in a master node of a cluster (210), the method (600) comprising: receiving, an access request from a user having one of a system defined roles to access a computational resource; identifying, the access request as one of: an allowable access request providing access to the at least one computational resource; transmitting, a pending request to at least one second control system (214), when the access request has been identified as a pending access request; receiving, a matched user profile from the at least one second control system (214); andgenerating, an access response for the access request according to the matched user profile.

11. The method (600) according to claim 10, wherein the plurality of system defined roles comprises at least one of a default role and a custom role.

12. The method (600) according to claim 11, wherein the default role comprises at least one of: a cluster admin role, an admin role, an edit role and a view role.

13. The method (600) according to any claim 10 to 12, wherein the method (600) further comprises: updating, the system defined role of the user to an updated role based on the matched user profile and the data associated with the system defined role of the user, when the access request is allowed.

14. The method (600) according to any claim 10 to 13, wherein the method (600) further comprises: rejecting the access request, when the matched group profile is identified as a profile of non-active users in the orchestration system (202).

15. The method (600) according to any claim 10 to 14, wherein the matched user profile comprises a user profile matched with the at least one clustering model (216) based on the system defined role.

16. A first control system (206) implemented in a master node (208) of a cluster (210) of the orchestration system (202), the first control system (206) comprising a controlling circuitry (306) configured to cause: receiving, an access request from a user having one of a system defined roles to access a computational resource; identifying, the access request as one of: an allowable access request providing access to the at least one computational resource; transmitting, a pending request to at least one second control system, when the access request has been identified as a pending access request; receiving, a matched user profile from the at least one second control system; andgenerating, by the first control system (206), an access response for the access request according to the matched user profile.

17. A method (700) for managing user access control to one or more computational resources in an orchestration system (202), wherein the orchestration system (202) is configured with a plurality of system defined roles for use in providing access to the at least one computational resource, wherein the method (700) is implemented in a second control system of the orchestration system (202), the method (700) comprising: receiving, a pending access request, when the access request has been identified as the pending access request by the at least one first control system (206); applying, at least one clustering model (216) over data associated with the system defined role of the user, wherein each clustering model (216) stores one or more user group profiles; matching, the data associated with the system defined role of the user with data of the one or more user group profiles to obtain a matched group profile for the system defined role of the user; and sending, the matched user profile to the at least one first control system (206), wherein, the at least one first control system (206) generates an access response according to the matched group profile.

18. The method (700) according to claim 17, wherein the plurality of system defined roles comprises at least one of a default role and a custom role.

19. The method (700) according to claim 28, wherein the default role comprises at least one of: a cluster admin role, an admin role, an edit role, a view role, a scheduler role, a volume scheduler role and a controller manager role.

20. The method (700) according to any claim 17 to 19, wherein the data of the one or more user group profiles comprise at least one of: historical data of the user, how long time the user has been within the orchestration system, number of access requests by the user per day, and a similarity score of the access request.

21. A second control system (214) implemented in a server (204) of a container-based system (200), the second control system (214) comprising a controlling circuitry (306) configured to cause:receiving, a pending access request, when the access request has been identified as the pending access request by the at least one first control system (206); applying, at least one clustering model (216) over data associated with the system defined role of the user, wherein each clustering model (216) stores one or more user group profiles; matching, the data associated with the system defined role of the user with data of the one or more user group profiles to obtain a matched group profile for the system defined role of the user; and sending, the matched user profile to the at least one first control system (206), wherein, the at least one first control system (206) generates an access response according to the matched group profile.

22. A computer program product comprising a non-transitory computer readable medium, having thereon a computer program comprising program instructions, the computer program is loadable into a data processing unit and configured to cause execution of the method according to any of claims 10 through 15 and 17 through 20 when the computer program is run by the data processing unit.

Images