Method for security analysis of a deployment file of a server cluster orchestration platform; Product computer program and associated orchestration platform.

Abstract

Method for security analysis of a deployment file of a server cluster orchestration platform; Product computer program and associated orchestration platform.This process includes the steps of: - extracting (151, 152, 153) from the deployment file a plurality of objects, each object being an instance of a generic object belonging to a library; - correlating (154) these objects with each other, obtaining a plurality of sets of objects each associated with a container or a grouping of container executions from the deployment file; - constructing (155) a graph containing nodes and links, each node corresponding to a container or a grouping of container executions, and each link corresponding to a security relationship between nodes connected by the link, and applying a plurality of security analyses to said graph to obtain a plurality of quantitative indicators for each of the nodes and links of the graph, scoring (156) these by calculating an overall vulnerability score from the different quantitative indicators; and - displaying (157) the graph enriched with the overall vulnerability scores.Figure for the abbreviation: Figure 4.

Description

Title of the invention: Method for security analysis of a deployment file of an orchestration platform for a server cluster; Associated computer program product and orchestration platform.

[0001] The general field of the present invention is that of security analysis of cloud computing infrastructures. More particularly, the invention relates to the security analysis of deployment files of microservices software applications.

[0002] There are different ways to develop a software application. Instead of creating a monolithic application, it can be advantageous to divide the application into a plurality of elementary services, or microservices, collaborating together.

[0003] This is typically the type of application found in cloud computing. The microservices of an application are deployed on one or more server clusters that make up the cloud.

[0004] Microservices are commonly deployed as containers. This is a lightweight virtualization method. The container(s) running on a host server in the server cluster share(s) the operating system kernel of that host server. Each container contains a microservice and a lightweight operating system. Within the container, the microservice runs in its own environment, as a completely autonomous application. The different containers associated with a microservices application communicate with each other, through suitable ports, on a virtual communication bus of the server cluster.

[0005] Deployment of a microservices application on a server cluster is performed using a server cluster orchestration server.

[0006] A deployment is performed manually through a series of commands or automatically through one or more deployment files. A deployment file defines a deployment template for the microservice application containers to be deployed. This file is interpreted by the orchestration server to perform the deployment of the application in the server cluster.

[0007] However, deployment files have become large (of the order of several thousand lines) so that their coding has become complex and their verification particularly difficult. More precisely, it is difficult to prepare a deployment file while guaranteeing the security of the corresponding deployment. Indeed, a deployment file offers little visibility on what is actually implemented. In particular, security aspects result from settings scattered at different levels of a deployment file. For example, while specific security settings have been defined for each container, general security settings may be defined at the container runtime group level. These general settings may then preempt all or part of what has been planned at the container level.

[0008] Thus, a poorly prepared deployment file can lead to a deployment with security flaws.

[0009] It therefore appears necessary to strengthen the security of cloud computing infrastructures by analyzing the deployment files of microservice applications to determine their security level and potential vulnerabilities.

[0010] In the following, we focus more specifically on the orchestration platform “Kubernetes” (registered trademark). This is an “open-source” software that, when run on an orchestration server, automates the deployment, scaling and implementation of application containers on clusters of servers. Kubernetes is widely used, but other orchestration platforms could just as easily be implemented, such as “Openshift” (registered trademark), “Rancher” (registered trademark), “Swarm” (registered trademark), “Nomad” (registered trademark), etc. In the Kubernetes environment, a group of container executions is called a pod

[0011] Document CN111737699A proposes a security hardening tool for the Kubernetes orchestration platform based on a guide prepared by the Center for Internet Security - CIS. This CIS guide proposes the best practices that should be implemented when using the Kubernetes orchestration platform.

[0012] This tool includes several modules including: an input module that processes deployment files, a security scanning module, a backup module, a security hardening module, and an output module.

[0013] This tool makes it possible in particular to automate a certain number of scans of deployment files based on rules from the CIS guide.

[0014] However, this tool does not allow automated scans based on rules other than the CIS recommendations. It would indeed be desirable to be able to scan deployment files based on different types of computer attacks.

[0015] Furthermore, this known tool does not provide an overall view of the security of the deployment model. In fact, each of the scans carried out by this tool is performed individually on the deployment file. In particular, the scans are each performed on a particular type of object in the deployment file. The output of this analysis is actually a simple checklist•

[0016] No results are thus put into perspective or correlated with other scan results to provide a more complete security report. For example, a configuration model that defines a first container exposed on the Internet, while being linked to a second container allowing an elevation of privileges, presents a very significant security risk that must be able to be identified, insofar as the first container constitutes a gateway allowing an attacker to access the second container from the Internet, to grant himself privileges there, then allowing him to read or write data in the microservices or their execution environment.

[0017] Another major drawback of this known tool is that it does not allow all the rules of the CIS guide to be automated. Some of them must therefore always be carried out manually. This is for example the case of the rules in section 5 relating to policies ("Policies") of the CIS guide.

[0018] The present invention therefore aims to respond to these problems.

[0019] For this purpose, the invention relates to a method for analyzing the security of a deployment file suitable for being interpreted by an orchestration server of a cluster of servers to carry out a deployment of a microservices application. This method comprises the steps of:

[0020] - extracting from the deployment file a plurality of objects, each object being a instance of a generic object and each generic object belonging to a library of predefined generic objects;

[0021] - correlate the objects of the plurality of objects with each other, so as to define a a plurality of sets of objects, each set of objects being associated with a container of the deployment file or a runtime grouping of containers of the deployment file;

[0022] - develop a graph comprising nodes and links, each node corresponding to a container of the deployment file or to an execution grouping of containers of the deployment file, and each link corresponding to a security relationship between the two nodes connected by the link and applying a plurality of security analyses on said graph so as to obtain a plurality of quantitative indicators for each of the nodes and links of the graph;

[0023] - rate each of the nodes and links of the graph by calculating an overall score of vulnerability based on different quantitative indicators; and

[0024] - display the enriched graph of global vulnerability scores on an interface man-machine of the orchestration server.

[0025] According to particular embodiments, the method comprises one or more of the following characteristics, taken in isolation or in all technically possible combinations.

[0026] The deployment file is a file in YAML format.

[0027] The method comprises a step of analyzing and a step of converting the deployment file to obtain a serialized document, from which the plurality of objects are extracted.

[0028] The method comprises, while the serialized document comprises key-value pairs, an aggregation step making it possible to instantiate the plurality of objects from the serialized document and a library of generalized objects.

[0029] The orchestration server runs a Kubernetes orchestration platform, the deployment file then comprising containers and pods, the pods being execution groupings of the containers.

[0030] The plurality of security analyses is selected from a set comprising:

[0031] - container vulnerabilities;

[0032] - pod security policies;

[0033] - accessibility of pod services;

[0034] - pod service accounts;

[0035] - network policies between pods; and,

[0036] - affinities and anti-affinities between pods.

[0037] The method comprises a step consisting of rating each of the nodes and links of the graph by calculating an overall danger score from the vulnerability scores and a matrix of attack techniques grouped by objective.

[0038] The attack technique matrix is ​​the MITRE ATT&CK matrix.

[0039] The invention also relates to a computer program product comprising software instructions which, when executed by a computer, implement a method for analyzing the security of a deployment file suitable for being interpreted by an orchestration server of a cluster of servers to carry out a deployment of a microservices application as briefly described above.

[0040] The invention also relates to a server for orchestrating a cluster of servers, capable of executing the computer program as briefly described above to implement a method for analyzing the security of a deployment file capable of being interpreted by a server for orchestrating a cluster of servers to carry out a deployment of a microservices application as briefly described above.

[0041] The invention and its advantages will be better understood upon reading the following detailed description of a particular embodiment, given solely for illustrative purposes. non-limiting example, this description being made with reference to the attached drawings in which:

[0042] [Fig.l] [Fig.l] is a schematic representation of a cloud computing infrastructure comprising an orchestration server according to the invention;

[0043] [Fig.2] [Fig.2] is a representation in the form of functional units of the orchestration server of [Fig.l];

[0044] [Fig.3] [Fig.3] is a security graph obtained by the orchestration server of [Fig.2]; and,

[0045] [Fig.4] [Fig.4] is a representation in the form of blocks of the process according to the invention. General structure

[0046] [Fig.l] schematically represents a cloud computing infrastructure, or infrastructure 1. It executes one or more application(s). A user 6, who accesses the infrastructure 1 via the Internet 7, will be able to benefit from one or more of these applications.

[0047] The infrastructure 1 is structured so as to form a cluster of servers. The infrastructure 1 comprises an orchestration server (or “master server(s)”) 3, a plurality of application servers (or “slave servers”) 2, and a communication network 4 which connects the different servers to each other and to the Internet 7. Alternatively, the infrastructure could comprise several orchestration servers and / or several clusters of servers connected via a network, for example the Internet. In [Fig.l], the plurality of application servers 2 comprises two servers 21 and 22.

[0048] Infrastructure 1 is adapted to implement the Kubernetes environment (as defined on the kubernetes website, for example at: https: / / kubemetes.io / fr / docs / concepts / overview / components / ). In the following, this environment will be described more particularly, but, alternatively, other types of environment can be implemented.

[0049] The plurality of application servers 2 execute one or more microservice applications. Each server executes one or more containers, i.e., a microservice and its environment.

[0050] In the Kubernetes environment, a container is encapsulated in a "pod" (or capsule). A pod comprises one or more containers that are guaranteed to be co-located on a host machine and share the resources of this host machine. A server can run several pods. Thus, in the Kubernetes environment, the smallest possible deployment unit is a pod. Each pod (or rather all instances of the same pod) has a unique IP address within the plurality of application servers 2.

[0051] An application results from the execution of different microservices, each microservice being contained in a container, itself encapsulated in a pod.

[0052] Thus, for example, the application server 21 executes the pods 211, 212 and 213, which respectively integrate the containers 214, 215 and 216, and 217. Thus, the application server 22 executes the pods 221, 222, 223 and 224, which respectively integrate the containers 225, 226, 227, and 228 and 229.

[0053] The orchestration server 3 makes it possible to automate the deployment, scaling and implementation of the containers of the microservice applications on the plurality of application servers 2.

[0054] The orchestration server 3 comprises an application programming interface server, or API server 32, a database 34, a scheduler 36 and a controller 38. The orchestration server 3 also comprises a human-machine interface, HMI 30, allowing an operator to interact with the orchestration server 3.

[0055] The API server 32 provides a set of definitions and protocols that facilitate the creation and integration of management applications of the plurality of application servers 2. By means of the HMI 30, the operator can access the API server 32 so as to edit, configure and execute the management applications.

[0056] The database 34 is a storage space for sensitive data. It is preferably a key-value store, such as for example the “etcd” store of the Kubernetes orchestration environment. The management applications read and write data in the database 34. The database 34 stores in particular the data, transmitted from the servers of the plurality of application servers 2, making it possible to represent the state of the plurality of application servers 2 at any time during its operation.

[0057] The database 34 also stores deployment files, as well as maintenance data to ensure the redundancy and resilience of a deployment.

[0058] A deployment file defines a template for deploying a microservices application.

[0059] A deployment file indicates the different containers and pods involved in the deployment, as well as the configuration of each of these components.

[0060] A deployment file is constructed by an operator, possibly from a suitable “template”.

[0061] The scheduler 36 has the function, during a deployment, of selecting the server of the plurality of application servers 2 on which each pod of a deployment will be executed. The factors taken into account for the scheduling decisions include in particular the individual and collective resource requirements, the constraints on hardware, software, policies, affinity and anti-affinity specifications, data locality, and / or workload interference and deadlines.

[0062] The controller 38 is capable of performing different control tasks either of the Kubernetes orchestration or of the plurality of application servers 2.

[0063] Kubernetes orchestration controls include, for example: detecting and responding in terms of redeployment when a slave server goes down; maintaining the correct number of replicas of a pod; creating default accounts and tokens for API server access.

[0064] The controls of the plurality of application servers 2 are for example: determining whether a server has been deleted in the cluster after having stopped responding; setting up routes in the server cluster; creating, updating and deleting load balancers provided by the server cluster; creating, attaching and mounting storage volumes on the application servers of the cluster.

[0065] For orchestration, an application server further comprises several functional modules for managing, in coordination with the orchestration server 3, the execution of the pods.

[0066] An application server comprises, for example, a “kubelet” module, a “kube-proxy” module and a “cAdvisor” module. For example, the server 21 comprises a “kubelet” module 23, a “kube-proxy” module 25 and a “cAdvisor” module 27, while the server 22 comprises a “kubelet” module 24, a “kube-proxy” module 26 and a “cAdvisor” module 28.

[0067] A “kubelet” module takes into account a set of specifications provided to it by the orchestration server 3 to ensure the proper functioning of each container and / or pod running on the application server on which the “kubelet” module is running. A “kubelet” module supports the starting, stopping, and maintenance of containers organized into pods. A “kubelet” module monitors the state of a pod and if it is not in the desired state, the pod will be redeployed on the same host application server.

[0068] A "kube-proxy" module is a network proxy capable of maintaining network policies on application servers. These network policies enable network communication to pods from network sessions inside or outside the server cluster.

[0069] A “cAdvisor” module analyzes memory, CPU, file and network usage metrics for all containers and / or pods running on the application server on which the “cAdvisor” module is executed. This analysis data is repatriated into the database 34 and participates in determining the current state of the infrastructure 1. The status of a host application server is relayed to interval of a few seconds via status messages to the orchestration server. As soon as the latter detects a fault on an application server, the controller 38 sees this change of status and launches the pods on other application servers of infrastructure 1.

[0070] Furthermore, each application server executes a container and / or pod runtime environment module. This is software responsible for running the containers. In [Fig.l], the module of the first application server 21 is referenced 231 and that of the application server 22 is referenced 232. Kubernetes is compatible with several known container runtime environments: “Docker”, “containerd”, “cri-o”, “rktlet” as well as any implementation of the container runtime interface - CRI (“Container Runtime Interface”) of Kubernetes. Analysis module

[0071] According to the invention, the infrastructure 1 comprises a security analysis module 50. This module is preferably executed on an orchestration server, such as the server 3, but, as a variant, it could be executed on another machine of the infrastructure 1.

[0072] The security analysis module 50 has the function of analyzing a deployment file, for example from the database 34, before its deployment, so as to identify security problems therein and to help the operator of the orchestration server 3 to adapt this deployment file as a result of the identified problems.

[0073] Module 50 is a computer program comprising several functional units.

[0074] In the embodiment shown in [Fig.2], the module 50 comprises a syntactic analysis unit 51, a conversion unit 52, an aggregation unit 53, a correlation unit 54, a graph generation and security analysis unit 55, a notation unit 56 and a display unit 57.

[0075] Module 50 takes as input a deployment file F_Config.

[0076] A deployment file describes the different components of the corresponding deployment model: containers, pods, container configurations, pod configurations, pod security policies, etc.

[0077] Configuring a pod includes: allocating memory and CPU resources to the pod; defining a volume for storing files associated with each container in the pod; configuring service accounts for that pod (a "ServiceAccount" service account gives an identity to each process running in a pod); retrieving an image from a private registry (a pod can use a "Secret" code to be able to retrieve data from a private registry); configuring the pod's probes that will be used by the associated "Kubelet"; assigning a pod to a particular machine in the server cluster; configuring pod initialization before being able to run the container or one of its containers; share the namespace of processes between the containers of a pod (when sharing this space is enabled, the processes of a container are visible to all the other containers of this pod)...

[0078] The security policy of a pod consists in particular of: defining objects of type "NetworkPolicy" acting as firewall rules between the pods; defining objects of type "Role" attributing authorizations at the level of a "Namespace" and "RoleBinding" linking a Role to a ServiceAccount; defining objects of type "ClusterRole" attributing authorizations at the level of the server cluster and "ClusterRoleBinding" linking a "ClusterRole" to a "ServiceAccount"; defining objects of type "Security Context" attributing parameters for controlling privileges and access for a pod.

[0079] In one possible embodiment, the method supports deployment files in YAML format, preferably respecting the syntax of the Kubemetes environment.

[0080] An example of an excerpt from a YAML deployment file is given below:

[0081] —

[0082] apiVersion: vl

[0083] kind: Secret

[0084] metadata:

[0085] name: rabbitmq

[0086] labels:

[0087] app: rabbitmq

[0088] chart: rabbitmq-6.16.6

[0089] type: Opaque

[0090] data:

[0091] rabbitmq-password: "Y2hhbmdlbWU="

[0092] rabbitmq-erlang-cookie: "QWRaMjNOQlVteWJEeEVLcFZxY 09iMnk5TDlBREFVang="

[0093] —

[0094] apiVersion: vl

[0095] kind: Service

[0096] metadata:

[0097] name: rabbitmq-headless

[0098] labels:

[0099] app: rabbitmq

[0100] chart: rabbitmq-6.16.6

[0101] spec:

[0102] clusterlP: None

[0103] ports:

[0104] - name: epmd

[0105] port: 4369

[0106] targetPort: epmd

[0107] - name: amqp

[0108] port: 5672

[0109] targetPort: amqp

[0110] selector: [OUI] app : rabbitmq

[0112] —

[0113] apiVersion: vl

[0114] kind: ServiceAccount

[0115] metadata:

[0116] name: rabbitmq

[0117] labels:

[0118] app : rabbitmq

[0119] chart: rabbitmq-6.16.6

[0120] —

[0121] kind: Rôle

[0122] apiVersion: rbac.authorization.k8s.io / vl

[0123] metadata:

[0124] name: rabbitmq-endpoint-reader

[0125] labels:

[0126] app: rabbitmq

[0127] chart: rabbitmq-6.16.6

[0128] rules:

[0129] - apiGroups: [""]

[0130] resources: ["endpoints"]

[0131] verbs: ["get"]

[0132] —

[0133] kind: RoleBinding

[0134] apiVersion: rbac.authorization.k8s.io / vl

[0135] metadata:

[0136] name: rabbitmq-endpoint-reader

[0137] labels:

[0138] app: rabbitmq

[0139] chart: rabbitmq-6.16.6

[0140] subjects:

[0141] - kind: ServiceAccount

[0142] name: rabbitmq

[0143] roleRef:

[0144] apiGroup: rbac.authorization.k8s.io

[0145] kind: Rôle

[0146] name: rabbitmq-endpoint-reader

[0147]

[0148] apiVersion: apps / vl

[0149] kind: Pod

[0150] metadata:

[0151] name : rabbitmq

[0152] labels:

[0153] app: rabbitmq

[0154] chart: rabbitmq-6.16.6

[0155] spec:

[0156] serviceName: rabbitmq-headless

[0157] replicas: 1

[0158] updateStrategy:

[0159] type: RollingUpdate

[0160] selector:

[0161] matchLabels:

[0162] app: rabbitmq

[0163] template:

[0164] metadata:

[0165] labels:

[0166] app: rabbitmq

[0167] chart: rabbitmq-6.16.6

[0168] spec:

[0169] serviceAccountName: rabbitmq

[0170] containers:

[0171] - name : rabbitmq

[0172] image : docker, io / bitnami / rabbitmq : 3.8.2-debian-10-rO

[0173] imagePullPolicy: "IfNotPresent"

[0174] command:

[0175] - bash

[0176] -1

[0177] mkdir -p / opt / bitnami / rabbitmq / .rabbitmq /

[0178] exec rabbitmq-server

[0179] ports:

[0180] - name: epmd

[0181] containerPort: 4369

[0182] - name: amqp

[0183] containerPort: 5672

[0184] livenessProbe:

[0185] exec:

[0186] command:

[0187] -sh

[0188] -rabbitmq-api-chec "http: / / user:$RABBITMQ_PWD@ 127.0.0. l:15672 / api / health / node"

[0189] securityContext:

[0190] fsGroup: 1001

[0191] runAsUser: 1001

[0192] —

[0193] The analysis unit 51 is capable of syntactically analyzing the configuration file F_config in order to extract key-value pairs from it.

[0194] The conversion unit 52 is capable of converting the key-value pairs into a data structure more suited to the programming language used. One of the possible implementations is the serialization of the key-value pairs using the JSON format, for a module 50 using the “Python” programming language. The JSON (“JavaScript Object Notation”) format is a textual data format derived from the object notation of the JavaScript language. It makes it possible to represent structured information. Thus, at the output of the unit 52 is obtained a document, D_JSON, in JSON format. The module 52 is optional, since it only corresponds to a formatting of the key-value pairs to facilitate the processing carried out downstream.

[0195] The aggregation unit 53 processes the D_JSON document delivered by the unit 52 (or alternatively the key-value pairs provided by the unit 51).

[0196] Unit 53 also takes as input a library of object templates (or object patterns), for example Python object classes in one of the possible implementations. This library is predefined.

[0197] Object templates correspond to the main Kubemetes objects, which are: Namespaces, Pods, Deployments, DaemonSets, ReplicaSets, Containers, InitContainers, Services, ServiceAccounts, Roles, ClusterRoles, RoleBindings, ClusterRoleBindings, PodSecurityPolicies, NetworkPolicies, Secrets, Volumes, VolumeMounts, PersistentVolumes, PersistentVolumeClaims.

[0198] Each object template is defined by a plurality of attributes, preferably defined following the Kubemetes syntax.

[0199] Instantiating an object template corresponds to assigning a value to each attribute of this template, these values ​​coming from the D_JSON document.

[0200] The unit 53 thus has the function of instantiating a plurality of Obj objects from the data of the D_JSON document, each object responding to the format of the object template from which it derives.

[0201] For example, processing the deployment file extract given above results in the following plurality of objects:

[0202] pods

[0203] [{'name': 'rabbitmq', 'labels': {'app': 'rabbitmq', 'charf: 'rabbitmq-6.16.6'}, 'namespace': 'stable_spring-cloud-data-flow', 'name_chart': 'stable_spring-cloud-data-flow', 'selector': {'app': 'rabbitmq'}, 'replicas': 1, 'update_strategy': 'RollingUpdate', 'psps': [<k8s_components.PodSecurityPolicy object at 0xllll63880>], 'security_contexf : {'fsGroup': 1001, 'runAsUser': 1001], 'services': [<k8s_components.Service object at 0xllll4a340>], 'service_account_name': 'rabbitmq', 'service_accounf : <k8s_components.ServiceAccount object at 0x11116c220>, 'rôles': [<k8s_components.Role object at 0x11114a910>], 'role_binding': <k8s_components.RoleBinding object at 0xllll4a8b0>, 'final_rules': {'gef : ['endpoints']}}]

[0204] service_accounts

[0205] [{'name': 'rabbitmq', 'labels': {'app': 'rabbitmq', 'charf: 'rabbitmq-6.16.6'}, 'namespace': 'stable_spring-cloud-data-flow', 'name_chart': 'stable_spring-cloud-data-flow', 'automounf: True}]

[0206] services

[0207] [{'namespace': 'stable_spring-cloud-data-flow', 'name_chart': 'stable_spring-cloud-data-flow', 'type_svc': None, 'clusterlP': 'None', 'ports': [{'name': 'epmd', 'porf: 4369, 'targetPort': 'epmd'}, {'name': 'amqp', 'porf: 5672, 'targetPort': 'amqp'}], 'selector': {'app': 'rabbitmq'}}]

[0208] rôles

[0209] [{'name': 'rabbitmq-endpoint-reader', 'labels': {'app': 'rabbitmq', 'charf: 'rabbitmq- 6.16.6'}, 'namespace': 'stable_spring-cloud-data-flow', 'name_chart': 'stable_spring-cloud-data-flow', 'rules': [<k8s_components.Rule object at 0xllll4aa60>]}]

[0210] role_bindings

[0211] [{'name': 'rabbitmq-endpoint-reader', 'labels': {'app': 'rabbitmq', 'charf: 'rabbitmq-6.16.6'}, 'namespace': 'stable_spring-cloud-data-flow', 'name_charf: 'stable_spring-cloud-data-flow', 'role_ref_api_group': 'rbac.authorization.k8s.io', 'role_ref_kind': 'Rôle', 'role_ref_name': 'rabbitmq-endpoint-reader', 'subjects': [<k8s_components.Subject object at 0x11114a9a0>], 'service_accounts': [<k8s_components.ServiceAccount object at 0x11116c220>], 'rôle': <k8s_components.Role object at 0x11114a910>}]

[0212] secrets

[0213] [{'type_secret': 'Opaque', 'name': 'rabbitmq', 'labels': {'app': 'rabbitmq', 'chart': 'rabbitmq-6.16.6'}, 'namespace': 'default', 'name_chart': 'stable_spring-cloud-data-flow', 'data': {'rabbitmq-password': 'Y2hhbmdlbWU=', 'rabbitmq-erlang-cookie': 'QWRaMjN0QlVteWJEeEVLcFZxY09iMnk5TDlBREFVang='}} ]

[0214] containers

[0215] [{'name_chart': 'stable_spring-cloud-data-flow', 'name': 'rabbitmq', 'image': 'docker.io / bitnami / rabbitmq:3.8.2-debian-10-r0', 'image_pull_policy': 'IfNotPresent', 'command': ['bash', 'mkdir -p / opt / bitnami / rabbitmq / .rabbitmqAnexec rabbitmq-server\n'], 'secrets': [<k8s_components.Secret object at 0xlla509d00>], 'psp': <k8s_components.PodSecurityPolicy object at 0xlla509fl0>}]

[0216] pod_security_policies

[0217] [{'name_chart': 'stable_spring-cloud-data-flow', 'name': 'rabbitmq', 'labels': {'app': 'rabbitmq', 'chart': 'rabbitmq-6.16.6'}, 'namespace': 'stable_spring-cloud-data-flow', 'privileged': None, 'host_ipc': None, 'host_pid': None, 'host_network': None, 'host_ports': None, 'volumes': None, 'allowed_host_paths': None, 'allowed_flex_volumes': None, 'fs_group': 1001, 'read_only_root_file_sy stem': None, 'run_as_user': 1001, 'run_as_group': None, 'run_as_non_root': None, 'supplemental_groups': None, 'allow_privilege_escalation': None, 'default_allow_privilege_escalation': None, 'default_add_capabilities': None, 'required_drop_capabilities': None, 'allowed_capabilities': None, 'capabilities': None, 'allowed_proc_mount_types': None, 'se_linux': None, 'se_linux_options': None, 'sysctls': None}]

[0218] Units 51, 52 and 53 thus allow an interpretation of the content of the analyzed deployment file by atomizing the information contained in the file, then by gathering the elementary information thus obtained in simple objects, each object corresponding to the observation of a pod or a container from a certain angle.

[0219] Note that for a given object template, said object can be defined in various forms in the deployment file. For example, a "Secrets" object can be instantiated from a Kubernetes object called "Secret", but also from the definition of a container volume (if the secret type is a volume), itself defined in the definition of a pod, or from the "env" (for "environment") attribute of a container.

[0220] In addition, object instantiation requires a merger of information concerning the same object but scattered across several places in the deployment file. source. For example, the security policy of a container ("security context") is defined in the "securityContext" attribute of the container. A security policy can also be defined at the level of the pod containing the container, in two different places, namely in the "securityContext" attribute of the pod and / or in a "PodSecurityPolicy" object associated with the pod. If this is the case, the security policy of the pod preempts that of the container and a step of merging these various configurations is necessary to determine the policy that is actually defined for this component. The correlation unit 54 is then capable of associating the objects of the plurality of objects Obj with each other to constitute a plurality of sets of objects Ens. Each set is associated only with a pod or a container. The unit 54 exploits the relationships between the values ​​of the attributes of the objects Obj.For example, objects are grouped based on "nodeSelector" or "labelSelector" attributes, which are, in Kubernetes' own syntax, reference keys to other objects.

[0221] In the example above relating to a single pod, the unit 54 is capable of extracting a single set Ens comprising a total of seven objects, which in this example are all of different natures: a “pod” object in the “pods” list, a “service account” object in the “service_accounts” list, a “service” object in the “services” list, a “role” object in the “roles” list, a “role_binding” object in the “role_bindings” list, a “secret” object in the “secrets” list, a “container” object in the “containers” list and a “pod_security_policy” object in the “pod_security_policies” list.

[0222] From one list to another, the correlated objects and therefore belonging to the same set Ens are identified for example on the value of the key “name”.

[0223] Thus, for each pod and container in the deployment file, we obtain a set of Ens objects, these objects are of various natures, but they are correlated with each other.

[0224] The plurality of sets of Ens objects constitutes a coherent system for describing the deployment model associated with the analyzed file.

[0225] The graph generation and security analysis unit 55 comprises a first sub-module 551 and a second sub-module 552.

[0226] The first sub-module 551 is capable of developing a graph G from the plurality of sets of objects, Ens, delivered at the output of the correlation unit 54.

[0227] A graph G has nodes and links. A link connects two nodes.

[0228] Each node is a pod node (i.e., associated with a pod) or a container node (i.e., associated with a container) of the deployment file.

[0229] A link represents an interaction between the two nodes it connects. The connection can be asymmetric.

[0230] More specifically, a link between a pod node and a container node is an execution link indicating that this container is executed in or by this pod.

[0231] A link between two pod nodes indicates the possibility of a security flaw allowing the propagation of some form of attack from one pod to the other. These links between two pod nodes can be of different natures. For example, a link between two pod nodes can represent the absence or failure of a security policy governing communications between the connected pods. Indeed, network policies can be defined between two pods, to prohibit, authorize, or authorize under certain conditions (for example according to a particular protocol and / or a given list of ports) communications from one pod to another pod.

[0232] A link between two pod nodes can also materialize the presence or absence of affinities ("pod affinities") or anti-affinities ("pod anti-affinities") between two pods. This reflects the constraint that two pods must be located on the same server of the cluster, or on the contrary be located on two separate servers.

[0233] Finally, a last type of link between two pod nodes is the fact that a user in a pod can directly execute another pod, since the service account associated with it allows it (verb "exec" and resource "pod" in the role relating to the service account).

[0234] The second sub-module 552 applies different security analyses on the graph G in order to evaluate the degree of security of the analyzed deployment file and to provide quantitative indicators on the corresponding deployment model.

[0235] In particular, the security analyses actually applied include all (or more) of the following six analyses:

[0236] 1) Container vulnerability: for each container, we count the number of vulnerabilities whose danger is high or critical (alternatively, the number of vulnerabilities is retrieved via “open-source” tools such as “docker scan” which determines the operating system and libraries installed in the container, then links this information to vulnerability databases available online); for example, the standardized evaluation of the criticality of vulnerabilities “Common Vulnerability Scoring System” - CVSS is implemented, giving a score between 0 and 10; only the most critical vulnerabilities are counted, i.e. those with a CVSS score of preferably greater than 7;

[0237] 2) Accessibility of services associated with pods: we evaluate the accessibility policy microservices hosted on each of the pods, since, in a deployment file, the pods can be accessed either by the Kubernetes components, or inside the Kubernetes cluster, or even exposed outside the server cluster;

[0238] 3) Security policies associated with pods: we evaluate the vulnerability of the policies security of pods and the security configuration ("security context") of pods and containers; this analysis covers information defining the environment of pods and containers, such as the list of privileges (for example "Linux capabilities") that are prohibited or authorized and which are, therefore, potentially dangerous, the different types of authorized volumes, the permissions associated with files (read-only or write), the authorized users (administrator ("root") or not), the permission to launch privileged or non-privileged containers, the authorized or non-authorized use of the host machine's network and possibly the list of authorized ports, the authorized or non-authorized use of Linux "Namespaces" and process identifiers executed on the host machine, etc.;

[0239] 4) Service accounts associated with pods: we evaluate the service accounts of the pods and the permissions associated with them, such as the ability to create new pods, read secrets, run other pods, etc.;

[0240] 5) Network policies: we evaluate the firewall rules that govern interactions between pods, i.e. which pods can communicate with each other, on which port and according to which protocol;

[0241] 6) Affinities and anti-affinities between different pods: we evaluate the affinity of the different pods, that is, the fact that two pods must be located on the same host server ("pod affinity"), or on the contrary necessarily be located on two different host servers ("pod anti-affinity").

[0242] The application of each of these security analyses leads to the calculation of a plurality of indicators for each element of the graph G, whether it is a node or a link. We obtain a matrix M, the columns of which correspond to each of the nodes and links of the graph G and the rows of which correspond to each of the security analyses.

[0243] The scoring unit 56 associates an overall score with each of the nodes and links of the graph G.

[0244] According to a first security analysis scale, the unit 56 aggregates the different indicators of the matrix M. Optionally, a certain weighting is applied between the indicators, that is to say between the security analyses applied by the unit 55. A first overall score, or vulnerability score, is thus obtained for each node and each link of the graph G. This first rating scale gives an overall idea of ​​the vulnerability of the deployment model.

[0245] According to a second security analysis scale, unit 56 calculates danger sub-scores for each family of tactics in the MITRE ATT&CK matrix. It is indeed more relevant to qualify a deployment file according to the main attack techniques or phases of an attack.

[0246] The MITRE ATT&CK Matrix is ​​an up-to-date reference base of attack techniques grouped by objective (or tactic). In particular, the matrix is ​​composed of nine distinct families of tactics: "Initial access", "Execution", "Persistence", "Privilege escalation", "Defense evasion", "Credential access", "Discovery", "Lateral movement", and "Impact".

[0247] The MITRE ATT&CK matrix provides an assessment of the security level of deployment model configurations, through an accurate representation of the different attack techniques and their possible propagation within the deployment.

[0248] The G graph representation of the deployment file makes it easy to evaluate each type of attack in the MITRE ATT&CK matrix. The G graph allows the reconstruction of attack paths from the relationships between the elements of the graph and their vulnerability scores according to the first scale.

[0249] A danger sub-score for each type of attack in the MITRE ATT&CK matrix is ​​thus calculated.

[0250] A second overall score, or danger score, is obtained by aggregating the danger sub-scores, possibly by applying an appropriate weighting between the different types of attack.

[0251] Finally, the graph G is enriched by associating with each node and each link of the latter the global score according to the first scale (vulnerability score) and / or, possibly, the global score according to the second scale (danger score).

[0252] The display unit 57 is capable of displaying the enriched graph G* on the graphical interface 30.

[0253] This representation from a security point of view of the deployment file allows the operator to modify the analyzed deployment file to improve it by making it less vulnerable and less dangerous. The operator of the orchestration server can quickly identify the weak points of the deployment model. It is then easy for him to edit the deployment file, to modify one or more lines, and to restart the execution of the module 50 in order to evaluate the effects of the modification.

[0254] [Fig.3] gives an example of an enriched graph G* as it can be displayed on 1THM 30.

[0255] This graph represents the Helm chart deployment model: "spring-cloud-data-flow" of "stable".

[0256] Each circle represents a node in the graph: the larger circles represent the pods and the smaller circles represent the containers, which make up each of the pods.

[0257] A color code is assigned to each node of the enriched graph. For example, a more or less dark red is assigned to a node depending on the value of the vulnerability score that was calculated for this node. We can thus see that the containers have a rather low number of high or critical vulnerabilities (between 17 and 71). The implementation of the invention makes it possible to scan the vulnerabilities of all the nodes representing containers, while some of them could not be scanned by state-of-the-art tools.

[0258] Some pods have permissions to create new pods, read secrets, and run other pods. As a result, their danger score is high.

[0259] The rich graph display can represent different types of links between pods. For example, in [Fig.3], the links represent the fact that there are no firewall rules between connected pods. In another rich graph display, the links shown represent execution links, i.e., the user of one pod has the ability to move to another pod. Process

[0260] The method 100 according to the invention consists of executing the module 50.

[0261] As illustrated in [Fig.4], it comprises the following steps:

[0262] In a step 151, the unit 51 is executed to syntactically analyze a deployment file F_Config and extract key-value pairs therefrom.

[0263] In a step 152, the unit 52 is executed to convert the key-value pairs and construct a D_JSON document.

[0264] In a step 153, the unit 53 is executed to aggregate the information of the D_JSON document to obtain a plurality of Obj objects.

[0265] In a step 154, the unit 54 is executed to correlate the objects Obj with each other to gather them into a plurality of sets Ens.

[0266] The method 100 continues with a step 155 of executing the graph generation and security analysis unit 55 to construct a graph G from the plurality of sets Ens and apply different security analyses to the objects of this graph in order to evaluate the degree of security of the deployment model. This results in the calculation of different indicators.

[0267] In a step 156, the scoring unit 56 is executed to calculate a vulnerability score and advantageously a danger score for each of the elements of the graph, nodes and links.

[0268] Finally, in step 157, the display unit 57 is executed to display on the human-machine interface 30 an enriched graph G* obtained at the end of step 156, associating with each element of the graph the score(s) obtained. Benefits

[0269] The present invention is based on the use of a graph making it possible to represent the components of a deployment according to different security-related aspects in order to evaluate the associated risks.

[0270] The present invention makes it possible to correlate various security characteristics of a deployment model: interaction between the various units, co-location of the units on different physical machines, resilience metrics, user permissions, authentication and authorization modes, etc.

[0271] Of particular interest, a deployment model is evaluated against characteristic attack types (such as those defined in the MITRE ATT&CK environment) to assess how the proposed deployment performs against various types of computer attacks.

[0272] The present invention, by providing graphical modeling of a deployment file from a security perspective, makes it possible to increase visibility in this type of environment, so that developers and administrators can know what they are actually implementing and the potential security risks that this implies. It is therefore an aid to decision-making with a view to applying remediation methods and security patches in a cloud infrastructure configuration.

[0273] Thus, the invention, beyond the identification of certain potentially dangerous deployment models, offers a means of remedying the identified weaknesses.

Claims

1. Claims Method (100) for security analysis of a deployment file (F_Config) suitable for being interpreted by an orchestration server (3) of a server cluster (1) to carry out a deployment of a microservices application, characterized in that it comprises the steps of: - extracting (151, 152, 153) from the deployment file a plurality of objects (Obj), each object being an instance of a generic object and each generic object belonging to a library of predefined generic objects; - correlating (154) the objects of the plurality of objects with each other, so as to define a plurality of sets of objects (Sets), each set of objects being associated with a container of the deployment file or with an execution grouping of containers of the deployment file; - developing (155) a graph (G) comprising nodes and links, each node corresponding to a container of the deployment file or to an execution grouping of containers of the deployment file, and each link corresponding to a security relationship between the two nodes connected by the link, and applying a plurality of security analyses on said graph so as to obtain a plurality of quantitative indicators for each of the nodes and links of the graph; - rate (156) each of the nodes and links of the graph by calculating an overall vulnerability score from the different quantitative indicators; - score each of the nodes and links of the graph by calculating an overall danger score from the vulnerability scores and a matrix of attack techniques grouped by objective; and, - display (157) the graph (G) enriched with the overall vulnerability and danger scores on a human-machine interface (30) of the orchestration server, the deployment file (F_Config) comprising containers and “pods”, the “pods” being execution groupings of the containers, the plurality of security analyses which is applied is selected from a set comprising: - container vulnerabilities; - pod security policies; - pod service accessibility; - pod service accounts; - inter-pod network policies; and, - pod affinities and anti-affinities.

2. The method of claim 1, wherein the deployment file (F_Config) is a file in YAML format.

3. Method according to claim 1 or claim 2, comprising a step of analyzing (151) and a step of converting (151) the deployment file to obtain a serialized document (D_JSON), from which the plurality of objects (Obj) is extracted.

4. Method according to claim 3, comprising, while the serialized document comprises key-value pairs, an aggregation step (153) making it possible to instantiate the plurality of objects (Obj) from the serialized document and a library of generalized objects.

5. A computer program comprising software instructions which, when executed by a computer, implement a method according to any one of claims 1 to 4.

6. Server for orchestrating a cluster of servers, capable of executing the computer program of claim 5 to implement a method according to any one of claims 1 to 4.

Images