FR3070778A1 - SYSTEM AND METHOD FOR AUTHENTICATING COMPUTER RESOURCE MANAGEMENT INSTRUCTIONS FROM A VIRTUALIZATION SERVER - Google Patents

Abstract

The invention relates to a computer resource management instruction authentication system comprising: at least one virtualization server (SV) having computer resources and comprising: at least one virtual machine (VM1, VM2, VM3) in which all or part of the computing resources are allocated,? a virtual machine manager (VMM) adapted to perform a virtualization server (SV) computing resource management operation according to an orchestration instruction, - at least one orchestrator (ORCH) adapted to provide the instruction of orchestration, characterized in that the system further comprises an authentication device (VMOA) adapted to perform an authentication operation of the orchestration instruction provided by the orchestrator (ORCH), which operation of Authentication is performed before the Manager (VMM) executes the management operation.

Description

SYSTEM AND METHOD FOR AUTHENTICATING COMPUTER RESOURCE MANAGEMENT INSTRUCTIONS OF A VIRTUALIZATION SERVER

Description

Technical field of the invention.

The subject of the invention is a system and a method for authenticating instructions for managing computer resources of at least one virtualization server, that is to say a server that can carry virtual machines.

It concerns the technical field of information management systems and, more specifically, the management of IT resources in a virtualized environment.

State of the art.

"Virtualization" is a computer technique consisting in running several operating systems, servers or applications, on the same physical server. A virtual IT infrastructure provides the ability to manage pooled IT resources across a business, helping to better meet dynamic organizational needs and get the most out of infrastructure investments.

A virtual IT infrastructure generally includes one or more virtualization servers, each with IT resources.

-2All or part of these IT resources are allocated in a plurality of virtual machines (or VM for Virtual Machine) isolated from each other, and each equipped with a computer operating system and applications. Each VM is an autonomous and independent entity. Installing multiple VMs allows you to run different operating systems and applications on a single physical server, or "host."

A VM Manager (or VMM for Virtual Machine Manager), also known as a hypervisor, performs operations to manage the virtual server’s computing resources based on instructions. The formulation of such instructions can be outsourced and taken in charge by an orchestrator who, thanks to a global vision of the states of the different virtualization servers and of the network interconnecting them, is able to make better global decisions compared to the case where the server would make such decisions autonomously, based on information local to the server. When the instructions are formulated by an orchestrator and then sent to the virtualization servers for execution, we speak of an orchestration instruction. An instruction is here a request carrying an order which must be carried out by the receiver. In practice, the VMM receives instructions from the orchestrator on how to create, destroy, modify, copy, migrate VMs, manually or automatically. In addition, the VMM provides specific functionality to run multiple separate operating systems. The VMM generally consists of a software layer adapted to decouple the VMs from the host and dynamically allocate IT resources to the different VMs as needed.

This architecture of virtualized IT infrastructures is sensitive to attacks that can come from different horizons. In particular, by generating spurious orchestration instructions, a malicious person can obtain the malicious creation, destruction, modification, copy or migration of VM to, for example, carry out external attacks of DDOS type (for

-3 English Distributed Déniai Of Service) aimed at making the host, a service and / or the IT infrastructure unavailable, by overloading the bandwidth or monopolizing IT resources until exhaustion. Internal attacks are also possible, such as MITM (man-inthe-middle) attacks designed to intercept communications between elements of the IT infrastructure, attacks aimed at falsifying or affecting data integrity.

The invention aims to remedy this state of affairs. In particular, an objective of the invention is to protect and secure virtualization servers and their virtual machines.

Another objective of the invention is to secure the communication between the orchestrator and the VMM, to guarantee that an orchestration instruction is authorized and legitimate.

Disclosure of the invention.

The solution proposed by the invention is an authentication system for computer resource management instructions comprising:

- at least one virtualization server with IT resources and comprising:

o at least one virtual machine in which all or part of the computer resources are allocated, o a virtual machine manager adapted to execute an operation for managing the computer resources of the virtualization server as a function of an orchestration instruction,

- at least one orchestrator suitable for providing the orchestration instruction.

The system further includes an authentication device adapted to perform an authentication operation of the orchestration instruction provided by the orchestrator, which authentication operation is performed before the manager performs the management operation.

The authentication device therefore makes it possible to authenticate each orchestration instruction. In the event of negative authentication, the orchestration instruction is not executed by the manager. This solves the problem of unauthorized execution of malicious orchestration instruction and avoids the implementation of operations of creation, migration, modification, copying or destruction of unauthorized virtual machine (s).

Other advantageous features of the invention are listed below. Each of these characteristics can be considered alone or in combination with the remarkable characteristics defined above, and be the subject, if necessary, of one or more divisional patent applications:

Advantageously, the orchestration instruction provided by the orchestrator is included in a request transmitted by said orchestrator to the authentication device (VMOA for Virtual Machine Orchestrator Authenticator); this orchestration instruction is only transmitted by the orchestrator to the manager after the VMOA authentication device has performed the authentication operation and transmitted to the orchestrator an authentication validation response.

Advantageously, the instruction received by the manager is included in a request transmitted by said manager to the VMOA authentication device; the manager executes the management operation only after the VMOA authentication device has executed the authentication operation and transmitted to the manager an authentication validation response.

- According to one embodiment, the orchestrator is identified by a unique identification data; the manager is identified by a unique identification data; the VMOA authentication device includes a database

-5in which a table is associated associating the identification data of the orchestrator with the identification data of the manager.

- The request received by the VMOA authentication device advantageously contains a data item identifying the orchestrator and a data item identifying the manager; during the authentication operation, the VMOA authentication device interrogates the table to verify that the identification data contained in the request correspond to the identification data contained in the table; the VMOA authentication device is suitable for generating and transmitting the authentication validation response, on condition that the identification data contained in the request correspond to the identification data contained in the table.

- The table recorded in the database of the VMOA authentication device is preferably adapted to memorize the nature and quantity of the computer resources available in the virtualization server; the request received by the VMOA authentication device also contains information concerning: the nature of the management operation to be executed, the nature and quantity of the IT resources necessary to perform this management operation; during the authentication operation, the VMOA authentication device performs a logical computer process of interrogating the table to verify that the nature and the quantity of computer resources available in the virtualization server makes it possible to perform the management operation said computer resources; the VMOA authentication device is suitable for generating and transmitting the authentication validation response, only on condition that the nature and quantity of the computer resources available in the virtualization server makes it possible to perform the operation for managing said authentication IT resources.

- According to one embodiment, the system comprises: - a plurality of virtualization servers each having IT resources and each comprising: at least one virtual machine in which all or part of the IT resources of the respective virtualization server are allocated; at least one virtual machine manager adapted to execute an operation for managing the computer resources of the respective virtualization server as a function of an orchestration instruction; - one or more orchestrators, each of said orchestrators being adapted to provide orchestration instruction to at least one of the managers; - the VMOA authentication device is adapted to execute an authentication operation for each orchestration instruction provided by the orchestrator (s).

- According to one embodiment, the VMOA authentication device consists of several authentication modules integrated in the manager and in the orchestrator, each of said modules receiving the orchestration instruction provided by the orchestrator and executing the authentication operation of said instruction independently.

- According to one embodiment, the system comprises: - a plurality of virtualization servers each having IT resources and each comprising: at least one virtual machine in which all or part of the IT resources of the respective virtualization server are allocated; at least one virtual machine manager adapted to execute an operation for managing the computer resources of the respective virtualization server as a function of an orchestration instruction; - one or more orchestrators, each of said orchestrators being adapted to provide orchestration instruction to at least one of the managers; - the VMOA authentication device consists of several authentication modules integrated in the managers and / or in the orchestrator (s); - each orchestration instruction provided by the orchestrator (s) is received by each of the authentication modules, which modules each execute an authentication operation in response to the reception of said instruction.

Each orchestration instruction provided by an orchestrator is advantageously received by each of the authentication modules, each manager being adapted to execute a management operation only if at least a predetermined number of authentication modules has executed an authentication operation. the orchestration instruction and generated an authentication validation response.

- Management operations are preferably recorded in blocks of a database system structured in blockchain. This database is advantageously distributed or duplicated in each of the authentication modules.

Another aspect of the invention relates to a method for authenticating instructions for managing computer resources of at least one virtualization server, comprising steps consisting in:

- provide an orchestration instruction,

- execute an operation of IT resources management of the virtualization server according to an orchestration instruction received.

The method further includes a step of executing an authentication operation of the orchestration instruction, which authentication operation is performed before the execution of the management operation.

Other advantageous characteristics of this process which is the subject of the invention are listed below. Each of these characteristics can be considered alone or in combination with the remarkable characteristics defined above, and be the subject, if necessary, of one or more divisional patent applications:

- The method can include the steps of: - including an orchestration instruction in a request; - transmit the request to several authentication modules integrated in a suitable manager to execute the management operation and in a suitable orchestrator to provide the orchestration instruction; - execute an authentication operation of the orchestration instruction included in the request, in each of the authentication modules.

- The method can also include the steps of: - including an orchestration instruction in a request; - transmit the request to several authentication modules integrated into several managers adapted to execute each of the management operations, and / or in several

-8 orchestrators adapted to each provide an orchestration instruction; perform an authentication operation of the orchestration instruction included in the request, in each of the authentication modules.

- Preferably, a management operation is only executed if at least a predetermined number of authentication modules has executed an authentication operation and generated an authentication validation response.

- The method advantageously comprises a step consisting in recording the management operations, in blocks of a database structured in blockchain.

The method advantageously comprises a step consisting in allocating effective resources and artificial resources to at least one orchestrator and to at least one virtualization server, so that: the artificial resources which the virtualization server has represent the computer resources which it are actually allocated at a given time and / or the IT resources used by at least one of its virtual machines running; the artificial resources that the orchestrator possesses represent the computing resources that it is actually capable of allocating to the virtualization server at a given time; the actual resources that the virtualization server has represent the computing resources that it is able to allocate to at least one of its virtual machines at a given time; the actual resources that the orchestrator has represent the computing resources used by at least one virtual machine running the virtualization server.

Advantageously, a management operation is executed by implementing an exchange of effective resources and artificial resources between the orchestrator and the virtualization server.

Advantageously, a transfer of effective resources, respectively of artificial resources, from the orchestrator to the virtualization server triggers a transfer of artificial resources, respectively of effective resources, from the virtualization server to the orchestrator.

Description of the figures.

Other advantages and characteristics of the invention will appear better on reading the description of a preferred embodiment which will follow, with reference to the appended drawings, produced by way of indicative and nonlimiting examples and in which:

FIG. 1 shows diagrammatically the arrangement of different components of a VMOA authentication device according to a first embodiment,

FIG. 2 illustrates an example of a system which is the subject of the invention comprising a VMOA authentication device according to the first embodiment,

FIG. 3 illustrates another example of a system which is the subject of the invention comprising a VMOA authentication device according to the first embodiment,

FIG. 4 illustrates different steps implemented in the method which is the subject of the invention, with a VMOA authentication device according to the first embodiment,

FIG. 5 illustrates an example of a system which is the subject of the invention comprising a VMOA authentication device according to a second embodiment,

FIG. 6 illustrates another example of a system which is the subject of the invention comprising a VMOA authentication device according to the second embodiment,

FIG. 7 illustrates different steps implemented in the method which is the subject of the invention, with a VMOA authentication device according to the second embodiment,

FIG. 8 illustrates stages of transactions involving artificial resources and effective resources,

- Figure 9a shows schematically a system object of the invention,

- Figure 9b illustrates a block of genesis of a blockchain, for the system of Figure 9a,

FIG. 10a illustrates exchanges of effective and artificial resources in the system of FIG. 9a, during the creation of a virtual machine,

- Figure 10b illustrates the blocks of a blockchain, following the exchange of resources in Figure 10a,

FIG. 11a illustrates exchanges of effective and artificial resources in the system of FIG. 10a, when resizing a virtual machine,

FIG. 11b illustrates the blocks of a blockchain, following the exchange of resources in FIG. 11a,

FIG. 12a illustrates exchanges of effective and artificial resources in the system of FIG. 11a, during the migration of a virtual machine,

- Figure 12b illustrates the blocks of a blockchain, following the exchange of resources in Figure 12a,

FIG. 13a illustrates exchanges of effective and artificial resources in the system of FIG. 11a, during the destruction of a virtual machine,

- Figure 13b illustrates the blocks of a blockchain, following the exchange of resources in Figure 13a.

Preferred embodiments of the invention.

The system and method which are the subject of the invention generate manipulations of physical elements, in particular signals (electrical or magnetic) and digital data, capable of being stored, transferred, combined, compared, etc., and allowing '' achieve a desired result.

The invention implements one or more computer applications executed by computer equipment. For the sake of clarity, it should be understood in the sense of the invention that "an equipment does something" means "the computer application executed by processor or microprocessor of the equipment does something". Just like "the computer application does

-11 something "means" the computer application run by the processor or microprocessor of the equipment does something ".

Again for the sake of clarity, the present invention refers to one or more “logical computer processes”. These correspond to the actions or results obtained by the execution of instructions from different computer applications. Also, it must also be understood in the sense of the invention that "a logical computer process is suitable for doing something" means "the instructions of a computer application executed by a processor or microprocessors do something".

Again for the sake of clarity, the following clarifications are made to certain terms used in the description and the claims:

- "Computer resource" can be understood in a nonlimiting way as: component, hardware, software, file, connection to a computer network, amount of RAM memory, hard disk space, throughput, bandwidth, processor speed, number of CPUs , etc.

- "Virtualization server" can be understood in a nonlimiting way as: virtualization server on the internet, virtualization server on Cloud, virtualization server on a platform, virtualization server on a local infrastructure, server networks, cluster, node, server farm, node farm.

- "Request" designates an execution order that can follow a communication protocol and includes input parameters (question) and return parameters (response), which can be in the form OK or ERROR in a format linked to the protocol used .

- “Orchestrator” can be understood in a nonlimiting way as: network services orchestration module; content orchestration system; automatic process of organization, coordination and management of complex IT systems, middleware and services; orchestration of service management, controller. The orchestrator can be a software platform that provides an entry point for organizing IT resources on the virtualization server and automating complex sets of operations for managing those resources. The orchestrator functions as a manager, capable of taking over all or part, by coordinating them, of the automated processes already in place. The orchestrator also provides additional functions for the development, management and supervision of the operations he performs.

- "Central processing unit" can be understood in a nonlimiting way as: processor, microprocessors, CPU (for Central Processing Unit).

- "Computer hardware" represents one or more spare parts of computer equipment and can be understood without limitation as hardware.

- "Software" can be understood as: computer application, computer programs or software.

- “Computer network” or “network” can be understood in a nonlimiting way as: computer bus, personal network (PAN), local network (LAN, WLAN, ..), wide area network (WAN), internet network, intranet network, extranet network. The computer network is a set of computer equipment linked together to exchange, securely or not, information and / or data according to a communication protocol (ISDN, Ethernet, ATM, IP, CLNP, TCP, HTTP,. ..).

- "Database" can be understood in a nonlimiting way as a structured and organized set of data recorded on supports accessible by computer equipment and which can be queried, read and updated. Data can be inserted, retrieved, modified and / or destroyed. The management and access to the database can be ensured by a set of software which constitute a database management system (DBMS).

According to the invention, the authentication of the orchestration instructions, generated and issued by the orchestrator, is ensured by a

- 13 authentication device (hereinafter designated by VMOA for Virtual Machine

Orchestrator Authenticator).

According to a first embodiment, the VMOA is in the form of a centralized server or computer platform, which can be considered as intermediate computer equipment between the orchestrator (s) and the VMM (s). In an alternative embodiment, the VMOA consists of several authentication modules described later in the description.

First embodiment (centralized VMOA).

In the first embodiment, the VMOA is centralized and can consist of a physical server or, in certain cases, be made up of several separate computers which communicate and interact over a network to perform the functions described further on in the description.

Referring to FIG. 1, the VMOA can in particular comprise a central processing unit 10, one or more memories 11, a network interface 12, a database 13, which are mutually connected via a bus

15. One or more software programs are stored in the memory or memories 11 and whose instructions, when executed by the processing unit 10, make it possible to carry out the functionalities described further on in the description.

The network interface 12 is a wired or wireless communication interface suitable for establishing communication, in particular with: one or more orchestrators and one or more VMMs. This communication is established via a computer network which is preferably secured so as to secure the exchange of data between the VMOA and the aforementioned equipment.

The computer database 13 can be hosted directly in the VMOA, or in another server or in a network of servers such as Cloud

- 14Computing, or in a computer. In the case where the database 13 is not located in the VMOA, and to secure the exchange of data between said VMOA and said base, the connection between these two devices is preferably carried out through a virtual private network (VPN), a secure internet network, or a wired link.

FIG. 2 illustrates an example of a system which is the subject of the invention. An ORCH orchestrator is adapted to provide orchestration instructions to the manager VMM of a virtualization server SV whose computer resources are allocated in a plurality of virtual machines VMi, VM ₂ , VM3. In this figure, three virtual machines are shown schematically by way of illustration, it being understood that the VMM can manage a greater or lesser number of virtual machines. The VMM, the ORCH orchestrator and the VMOA communicate through an R network to which they are connected.

In FIG. 3, the system comprises an integer n> 1 of orchestrators ORCH1, ..., ORCH _n . Each of these orchestrators is adapted to provide orchestration instructions to one or more managers, respectively VMMn-VMMi _m (m> 1) and VMM _n i-VMM _np (p> 1), of virtualization servers SV1, SV _n , whose IT resources are allocated in one or more virtual machines (not shown for the sake of clarity). The number of orchestrators and the number of managers, the number of virtualization servers and / or the number of virtual machines, can be fixed or vary over time. A single VMOA, common to ORCH1, ..., ORCH _n orchestrators and managers, VMMn-VMMi _m , ..., VMMni-VMM _np , is in charge of authenticating all the orchestration instructions issued by said orchestrators orchestrators. This common VMOA operates as a single node which is located and maintained in one place.

Each orchestrator and each manager is identified by a unique identification data (ID) which can for example consist of a code

- 15 unique alphanumeric or unique IP address. Each virtual machine can also be identified by a unique identification data (ID)

Each orchestrator is also paired with one or more managers to whom they are authorized to transmit orchestration instructions. In FIG. 2, the ORCH orchestrator transmits orchestration instructions only to the VMM manager. In FIG. 3, the orchestrator ORCHi transmits orchestration instructions only to the managers VMMn-VMMim and the orchestrator ORCH2 transmits orchestration instructions only to the managers VMM _n i-VMM _np . In other words, the ORCHi orchestrator is not authorized to transmit orchestration instructions to the VMM _n managers i i-VMM _np and the ORCH2 orchestrator is not authorized to transmit orchestration instructions to the VMMn managers -VMMi _m .

The IT resources available in the virtualization servers can be of different nature and of different quantity. For example, in FIG. 2, the virtualization server SV can have 100 GB (Giga Bytes) of RAM memory which can be managed by the manager VMM, the latter being able to distribute them in the various virtual machines VM1, VM2, VM3. In FIG. 3, the virtualization server SV1 can for example have 100 GB of RAM memory which can be managed by the VMMu manager, and a bandwidth of 100 GB / s (GigaBits per second) which can be managed by the VMMim manager. The virtualization server SVn can for example have 500 data files which can be managed by the VMMni manager and allocated to the associated virtual machines, and 200 GB of RAM memory which can be managed by the VMM _np manager.

The database 13 stores its various information in a table recorded in said database: nature and quantity of the computer resources available in each virtualization server, ID of each orchestrator, ID of each manager associated therewith. Other information may

- 16also be recorded in this table, such as timestamp data (date / time), ID of virtual machines, state of each virtual machine ("in progress", "destroyed", ...), allocation of resources in each virtual machine, etc.

Table 1 below illustrates a table recorded in the database 13, with reference to the aforementioned example relating to FIG. 2.

timestamp I Dorchestrator IDgestionnaire Nature of resources Quantity of resources Allocation of resources in the VMs T0 ORCH VMM Go 100 VMi: 20 VM _2: 20 VM _3: 60 T1 ORCH VMM Go 100 VMi: 15 VM _2: 20 T2 ORCH VMM Go 100 VMi: 15 VM _2: 20 VM _3: 65

Table 1

At time TO, the 100 GB of the virtualization server SV is distributed for 20 GB in the virtual machine VMi and for 20 GB in the virtual machine VM2. 60 GB remain available in the SV server.

At the moment T1, 5 GB are removed from the virtual machine VM1 which now has 15 GB. 65 GB remain available in the SV server.

At time T2, a VM3 virtual machine with 65 GB is created.

The database, and more particularly its table, is therefore a dynamic database, in the sense that the data it contains evolve over time and preferentially remain memorized and classified chronologically. More particularly, each management operation executed according to an orchestration instruction authenticated during an authentication operation, is recorded, classified and time stamped.

- 17In the framework of the architecture of Figure 2, the authentication of an orchestration instruction provided by the ORCH orchestrator will now be explained with reference to Figure 4:

- Step 1: The ORCH orchestrator generates and transmits to the VMOA a request in which the orchestration instruction is included. The latter can for example consist, without being limiting, in a creation, a destruction, a modification, a copy, a migration of the virtual machines. To follow the example above, this instruction is for example the allocation of 65 GB in a new VM3 virtual machine. In addition to the orchestration instruction, the request includes the ID of the ORCH orchestrator, the ID of the VMM manager, the nature of the management operation ("creation of a new virtual machine"), the nature ( "Go") and the quantity of these resources ("65") to be allocated to it.

- Event 2: The VMOA performs the authentication operation of the orchestration instruction. The reception of the request transmitted in step 1 is the trigger for this authentication operation. The VMOA queries the table recorded in the database 13 to at least verify that the identification data contained in the request correspond to the identification data contained in said table. In practice, the ORCH orchestrator ID and the VMM manager ID contained in the request must match the IDs contained in the table. Otherwise, the authentication operation will result in a failure.

Preferably, to further secure the management operation, the VMOA executes a more complex logical computing process by which, in addition to verifying the IDs, said VMOA verifies that the nature and quantity of the computer resources available in the virtualization server SV makes it possible to perform the IT resource management operation included in the request. In the above example, the VMOA queries the table to verify that the 65 GB to be allocated in the new virtual machine VM3, are indeed available, at time T, in the virtualization server SV. For example, if the amount of resources indicated in the request was 70 GB, that is to say

- 18Superior to the quantity available in the SV virtualization server, the authentication operation would result in a failure.

- Event 3: If the ORCH orchestrator ID and the VMM manager ID contained in the request match the IDs contained in the table, the VMOA generates an authentication validation response (OK). If the more complex logical computing process described in the previous paragraph is implemented, this authentication validation response is only generated on condition that the nature and quantity of the computing resources available in the SV virtualization server allow to carry out the management operation. Otherwise, the VMOA generates an authentication refusal response (ERROR).

- Step 4: The VMOA transmits the response to the request to the ORCH orchestrator.

- Step 5: The ORCH orchestrator transmits the orchestration instruction to the VMM manager. This instruction is only transmitted if the response to the request is a validation response (OK). If the response to the request is an ERROR response, the ORCH orchestrator is not authorized to transmit the orchestration instruction to the VMM manager.

- Event 6: The VMM manager executes the management operation according to the orchestration instruction received and authenticated. To follow the above example, the VMM manager creates the VM3 virtual machine and allocates it 65 GB.

- Step 7: Optionally, the VMM manager sends information to the VMOA indicating that the management operation has been correctly executed.

- Event 8: The VMOA updates the table and timestamps the newly recorded data. This update can however be performed during or after event 3, as soon as the VMOA generates an authentication validation response (OK).

To further secure the authentication process, upon receipt of the orchestration instruction transmitted by the ORCH orchestrator in step 5, the VMM manager can also ask the VMOA to authenticate this instruction. It is therefore a double authentication. Indeed a bad person

- 19 intended to control the ORCH orchestrator could still transmit the orchestration instruction to the VMM manager even if the response to the request is a response of refusal (ERROR). The steps and / or events below illustrate this double authentication process, and appear in Figure 4, below the dotted line:

- Step 5: The ORCH orchestrator transmits the orchestration instruction to the VMM manager.

- Step 9: The VMM manager generates and transmits to the VMOA a request in which is included the orchestration instruction received in step 5. In addition to the orchestration instruction, the request includes the orchestrator ID ORCH , the ID of the VMM manager, the nature of the management operation (“creation of a new virtual machine”), the nature (“Go”) and the quantity of these resources (“65”) to be allocated to it.

- Event 10: The VMOA performs the same operation for authenticating the orchestration instruction as that described above with reference to event 2.

- Event 11: If the ID of the ORCH orchestrator and the ID of the VMM manager contained in the request in step 9 correspond to the IDs contained in the table and if, if applicable, the nature and quantity of the resources IT available in the SV virtualization server allow the management operation to be carried out, the VMOA generates an authentication validation response (OK). Otherwise, the VMOA generates an authentication refusal response (ERROR).

- Step 12: The VMOA transmits the response to the request to the VMM manager.

- Step 13: Optionally, the VMM manager transmits to the ORCH orchestrator information indicating that the authentication of the orchestration instruction has been validated or refused by the VMOA.

- Event 14: The VMM manager executes the management operation according to the orchestration instruction received and authenticated.

- Step 15: Optionally, the VMM manager sends information to the VMOA indicating that the management operation has been correctly executed.

-20- Event 16: The VMOA updates the table and timestamps the newly recorded data. This update can however be performed during or after event 11, as soon as the VMOA generates an authentication validation response (OK).

In another alternative embodiment, the transmission of the orchestration instruction in step 5 can be carried out without the VMOA having previously authenticated said instruction (the aforementioned steps and events 1 to 4 are not implemented).

The authentication process which has just been described, applies identically in a more complex architecture such as that illustrated in FIG. 3, the common VMOA being adapted to execute an authentication operation for each orchestration instruction. provided by each of the ORCHi, ORCH ₂ orchestrators.

Second embodiment (non-centralized VMOA).

In a second embodiment, the VMOA is not centralized as in the aforementioned first embodiment, but distributed in one or more elements of the system and consists of several authentication modules (or agents).

In Figure 5, these VMOAorch, VMOAvmm authentication modules are integrated in the ORCH orchestrator and in the VMM manager. They can for example be in the form of computer hardware or software layers implemented in the ORCH orchestrator and in the VMM manager. In an alternative embodiment, only the ORCH orchestrator or only the VMM manager integrates a VMOAorch or VMOAvmm authentication module.

In FIG. 6, authentication modules VMOAorchi, VMOAoRCHn, VMOAvmmu, VMOAvMMim, VMOAvMMni, VMOAvMMnp, VMOAhost, are integrated in the orchestrator (s) ORCHi, ..., ORCH _n , in the managers VMMuVMMim, VMMni-VM and in the host server SH. In an alternative embodiment, only one or more of these pieces of equipment can integrate an authentication module (for example: the orchestrator ORCHi and the host server SH).

Each of these authentication modules integrates all or part of the database described above with reference to the first embodiment. The database is therefore distributed or duplicated, all or part of the data it contains resident in each of the authentication modules. This distribution of data can come from: - data fragmentation, each fragment being distributed in an authentication module (each of the authentication modules integrates a part of the database); or a replication (or duplication) of data, all of the data being replicated in each of the authentication modules (each of the authentication modules integrates the entire database). Each of the authentication modules is suitable for querying, reading and updating the distributed or duplicated database.

All authentication modules communicate with each other, via the R network or another computer network, so that the data in the database can be updated, depending on the orchestration operations carried out. For example, when the VMMu manager executes a management operation according to an orchestration instruction issued by the ORCHi orchestrator, the VMOAhost authentication module integrated in the host server SH is aware of this operation and updates the database accordingly.

-22 As part of the architecture of Figure 5, the authentication of an orchestration instruction provided by the ORCH orchestrator will now be explained with reference to Figure 7:

- Event 100: The ORCH orchestrator generates the request in which the orchestration instruction is included. The VMOAorch authentication module integrated into the ORCH orchestrator performs the authentication operation of the orchestration instruction (identical to event 2 above with reference to FIG. 4).

- Step 101: If the VMOAorch authentication module validates the authentication, the ORCH orchestrator transmits the orchestration instruction to the VMM manager.

- Event 102: The VMOAvmm authentication module integrated in the VMM manager performs the authentication operation of the orchestration instruction (identical to events 10 and 11 above with reference to Figure 4). Since the VMOAvmm authentication module performs the authentication operation of the orchestration instruction, the authentication operation performed by VMOAorch authentication module during event 100 is not necessary, although 'it provides more security to the system. Also, step 101 can be carried out even without validation of the authentication at the level of the ORCH orchestrator.

- Event 103: If the VMOAvmm authentication module validates the authentication, the VMM manager executes the management operation according to the orchestration instruction received.

- Event 104: The VMOAvmm authentication module updates the database and timestamps the newly recorded data. This update can however be performed during or after event 102, as soon as the VMOAvmm authentication module validates the authentication.

- Step 105: The VMOAvmm authentication module transmits to the VMOAorch authentication module information indicating that the management operation has been correctly executed.

- Event 106: The VMOAorch authentication module updates the database and timestamps the newly recorded data.

Each of the VMOAorch and VMOAvmm authentication modules therefore receives the orchestration instruction provided by the ORCH orchestrator and performs the authentication operation.

This authentication process applies identically in a more complex architecture such as that illustrated in FIG. 6. Each instruction provided by the orchestrator (s) ORCHi, ORCH2 is received by each of the authentication modules VMOAorchi, VMOAoRCHn, VMOAvmmu , VMOAvMMim, VMOAvMMn-i, VMOAvMMnp, VMOAhost, which modules each execute an authentication operation in response to the reception of said instruction.

An alternative embodiment is illustrated in FIG. 7, below the dotted line:

- Event 200: The ORCH orchestrator generates the request in which the orchestration instruction is included. The VMOAorch authentication module integrated in the ORCH orchestrator performs the authentication operation of the orchestration instruction independently.

- Step 201: Simultaneously with event 200, the VMOAorch authentication module transmits the request to the VMOAvmm authentication module integrated in the VMM manager.

- Event 202: The VMOAvmm authentication module autonomously performs the authentication operation of the orchestration instruction. The authentication operation is thus carried out simultaneously, or almost simultaneously, in each of the VMOAorch and VMOAvmm authentication modules. For the same reasons as those mentioned above for event 102, the authentication operation performed by the VMOAorch authentication module is not necessary.

- Step 203: If the VMOAorch authentication module validates the authentication, it transmits an authentication validation response to the VMOAorch authentication module. And if the VMOAvmm authentication module validates the authentication, it can also transmit an authentication validation response to the VMOAorch authentication module.

- Event 204: If the VMOAvmm authentication module validates the authentication and receives an authentication validation response from the VMOAorch authentication module, the VMM manager executes the management operation according to the orchestration instruction received. More generally and in a more complex architecture such as that illustrated in FIG. 6, it is conceivable that a manager can only execute a management operation on the condition that X% (with X> O, for example 50 <X <100) authentication modules have validated the authentication of the orchestration instruction.

- Event 205: The VMOAvmm authentication module updates the database and timestamps the newly recorded data. This update can however be performed during or after event 102, as soon as the VMOAvmm authentication module validates the authentication.

- Step 206: The VMM manager transmits to the ORCH orchestrator information indicating that the management operation has been correctly executed.

- Event 207: The VMOAorch authentication module updates the database and timestamps the newly recorded data.

This variant embodiment is applied identically in a more complex architecture such as that illustrated in FIG. 6 and makes it possible to replicate the authentication operation in each of the authentication modules. Thus, if one of the modules should fail to the point of no longer being able to perform the authentication operation, the latter is in all cases carried out redundantly in each of the other valid modules, thereby conferring increased resilience to the system.

In order to manage the consistency and / or coordination of the authentication modules, a conventional database management system (DBMS) can be provided to manage the distributed or duplicated database in all of the modules. One or more of the modules can be elected as master nodes serving as entry points for recording, in the distributed database, each authentication operation executed according to an authenticated orchestration instruction.

Third embodiment (database structured in blockchain).

The database can be structured in blockchain or blockchain and can be based on a decentralized consensus to record and validate authentication operations.

All management operations carried out according to authenticated orchestration instructions (hereinafter "transactions") are recorded in the blocks of a database structured in blockchain. After recording a transaction, a new block is generated and all new transactions will be validated by all or part of the network of authentication modules, which will analyze the complete history of the block chain. If the block is validated, it is time stamped and added to the block chain and becomes visible throughout the network. Once added to the chain, a block can no longer be modified or deleted, which guarantees the authenticity and security of the network. Each block can contain one or more management operations.

At startup, for the first time, at least one of the authentication modules creates a block of genesis, which is the first block of the blockchain. All subsequent transactions are stored in additional blocks chained together to build a block chain. Each block is timestamped and the timestamp data of a block contains the

- 26 timestamp data of the previous block, which constitutes a chain of timestamped blocks.

These blocks are linked together by a unique identifier that results from a fingerprint, or hash. Each block contains timestamp data, the details of one or more management operations, and the hash of the previous block which becomes the identifier of the block.

In this blockchain structure, a decentralized consensus protocol involving all or part of the authentication modules makes it possible to validate each transaction. The nodes involved in the validation of a transaction can be virtualization servers, managers, orchestrators, virtual machines, or any other dedicated or virtual hardware.

Within the framework of the architecture of FIG. 6, the authentication of an orchestration instruction supplied by an ORCHi orchestrator to a VMMni manager will now be explained:

- An ORCHi orchestrator generates a request in which is included an orchestration instruction for the VMMni manager.

- Simultaneously, the ORCHi orchestrator transmits the request to each node of the blockchain, that is to say to each authentication module VMOAorchi, VMOAoRCHn, VMOAvMMU, VMOAvMMIm, VMOAvMMnl, VMOAvMMnp, VMOAhost.

- Each authentication module VMOAorchi, VMOAoRCHn, VMOAvmmu, VMOAvMMim, VMOAvMMnl, VMOAvMMnp, VMOAhost performs an authentication operation of the orchestration instruction independently. The authentication operation is thus carried out simultaneously, or almost simultaneously, in each of the authentication modules.

- Each authentication module VMOAorchi, VMOAoRCHn, VMOAvmmu, VMOAvMMim, VMOAvMMnl, VMOAvMMnp, VMOAhost having validated the authentication, transmits an authentication validation response to each other node of the blockchain, i.e. to each other authentication module.

- If each authentication module VMOAorch-i, VMOAoRCHn, VMOAvmmu, VMOAvMMim, VMOAvMMn-i, VMOAvMMnp, VMOAhost validates the authentication, the VMMni manager executes the management operation according to the orchestration instruction received. By applying a principle of consensus, it can be envisaged that the VMMni manager can only execute a management operation on condition that X% (with X> 0, for example 50 <X <100) of the authentication modules have validated authentication of the orchestration instruction.

- Each authentication module VMOAorch-i, VMOAoRCHn, VMOAvmmu, VMOAvMMim, VMOAvMMn-i, VMOAvMMnp, VMOAhost, including those that have not validated the orchestration instruction, update the data base and time stamp the transaction .

Example of resource management in a database structured in b / ockchain.

For the sake of simplification, and without being limiting, the hypothesis adopted is that computer resources of a single nature must be managed, for example a quantity of RAM memory. Two management cases can be provided at boot time:

i. All computer resources are owned by the orchestrator, the virtualization server having no resources, ii. All IT resources are held by a virtualization server, the orchestrator having no resources.

Case i) can be problematic while case ii) can facilitate implementation.

In the first case i), the orchestrator has enough resources to transfer to create a new virtual machine.

-28 In the first case, at boot time, the orchestrator has a sufficient number of resources to transfer for new virtual machines. Each new creation of a virtual machine corresponds to a transaction, with resources to be transferred from the orchestrator to said virtual machine. A problem can arise when the virtualization server must be released, for example following an orchestration instruction relating to the destruction or migration of virtual machines. A transaction must provide for the return of resources to the orchestrator. The latter must therefore generate an orchestration instruction in a situation where it is no longer the owner of the resources, but simply the recipient. Although technically possible, this situation does not really apply to a structured blockchain system, where the originator of such an instruction must be the owner of the resources to be transferred and not the recipient of these resources. Also, case i) can potentially generate a source of conflict and / or operational incompatibility.

In case ii), when the virtualization server releases its resources, the orchestrator must again generate an orchestration instruction in a situation where it is not the owner of the resources, but simply the recipient. Since the issuance of this instruction comes from the orchestrator and not from the virtualization server, it appeared interesting to design a double transaction: a first transaction from the orchestrator to the virtualization server which triggers a second transaction from the server virtualization to the orchestrator. This double transaction can also apply to case i) above.

The principle underlying this double transaction consists in conceiving a management operation (resulting from an orchestration instruction), as an exchange of two resources: effective resources subject to a first transaction (leading to the operation of desired management) and artificial resources subject to a second transaction. The artificial resources and the second transaction are artifacts created specifically to respect the

-29 constraints mentioned above linked to the directivity of transactions in a blockchain.

Actual and artificial resources have the same absolute value. For resources of the same kind: an amount of effective resources is exchanged for the same amount of artificial resources.

In the context of the invention, the two transactions are subject to the authentication method described above with reference to the second or third embodiment. Outside the scope of the invention, these two transactions can be executed without implementing this authentication process.

FIG. 8 illustrates the stages of this double transaction in a system comprising: an ORCH orchestrator and two virtualization servers SV1 and SV2. These elements communicate with each other through a communication network (not shown). The ORCH orchestrator includes a VMOAorch authentication module. Each virtualization server SVi, SV2 comprises at least one virtual machine VM1, VM2 and a manager VMM1, VMM2 integrating an authentication module VMOAvmmi, VMOAvmm2. The effective resources (for example an effective amount of RAM memory) are initially located in one of the virtualization servers SV1, SV2 or in the two servers.

Artificial resources represent a pledge of effective resources. To allocate resources to the virtualization server SV1 (for example in the case of creation or scaling up of the virtual machine VM1), the ORCH orchestrator must "buy" effective resources from the manager VMM1 (Figure 8 : step 1a) and “sell” the same amount of artificial resources to him as a pledge (Figure 8: step 1b). Symmetrically, when the virtualization server SV2 frees up resources (for example in the case of destruction or resizing by reduction of the virtual machine VM2), the ORCH orchestrator "sells" to the manager

-30VMM ₂ of the actual resources (Figure 8: step 2a) and "buys" the same amount of artificial resources from him (Figure 8: step 2b).

For each virtualization server SVi and SV ₂ , the artificial resources which it possesses represent the computer resources which are actually allocated to it at a given instant and / or the computer resources used by at least one virtual machine VMi, VM ₂ in the course of 'execution. For the ORCH orchestrator, the artificial resources that he owns represent the computing resources that he is really capable of allocating to the virtualization servers SVi and SV ₂ at a given time. Conversely, for each virtualization server SVi and SV ₂ , the effective resources that it has represent the computing resources that it is capable of allocating to its virtual machines VMi, VM ₂ at a given time. And for the ORCH orchestrator, the effective resources it has represent the computer resources used by at least one virtual machine VMi, VM ₂ running.

In the genesis block, all the artificial resources of the system are allocated to the ORCH orchestrator. And all the effective resources are allocated to the SVi and SV ₂ virtualization servers. The total number of artificial resources corresponds to the total number of effective resources, this number remaining unchanged at all times and at the end of each transaction. In other words an artificial resource systematically has an equivalent in effective resource. Resources are redistributed after each transaction.

The exchanges of effective and artificial resources will now be described by taking, by way of illustrative and nonlimiting example only, the succession of the following transactions (management operations):

1. Creation of a virtual machine.

2. Resizing a virtual machine.

3. Migration of a virtual machine.

4. Destruction of a virtual machine.

Initially (genesis), 256 GB of RAM memory is distributed for half in the virtualization server SVi and for half in the virtualization server SV ₂ . Under these conditions, the virtualization server SV1 and the virtualization server SV2 each hold 128 effective resources (128 GB of RAM memory) managed by their respective manager VMMi and VMM ₂ , and the orchestrator holds 256 (128x2) artificial resources. The difference between the number of effective resources and the number of artificial resources is therefore zero. FIG. 9a illustrates the system in the initial state, the virtualization servers SVi and SV ₂ not yet having virtual machines. Figure 9b schematizes a block of genesis of the blockchain where the letter "A" refers to artificial resources and the letter "E" to effective resources.

Figure 10a shows the transactions for creating a virtual machine VM1 with 64 GB of RAM in the virtualization server SV1. The ORCH orchestrator "sells" 64 artificial resources to the VMMi manager (step 1.64A) and "buys" 64 effective resources (step 2.64E). Figure 10b shows the blocks of the blockchain after this creation of a virtual machine.

Figure 11a shows schematically the resizing of the virtual machine VM1 by a reduction of 32 GB of RAM memory. The ORCH orchestrator "sells" 32 effective resources to the VMMi manager (step 1.32E) and "buys" 32 artificial resources (step 2.32A). Figure 11b shows schematically the blocks of the blockchain after this resizing.

Figure 12a shows the migration from the virtual machine VMi to the server SV2. The ORCH orchestrator “sells” 32 effective resources to the VMMi manager (step 1.32E) and “buys” 32 artificial resources from him (step 2.32A). The ORCH orchestrator “sells” 32 artificial resources to the VMM ₂ manager (step 1.32A) and “buys” 32 effective resources from him (step

-322.32E). Figure 12b shows the blocks of the blockchain at the end of this migration.

Figure 13a shows schematically the destruction of the virtual machine VMi. The ORCH orchestrator "sells" 32 effective resources to the VMM2 manager (step 1.32E) and "buys" 32 artificial resources (step 2.32A). Figure 13b shows the blocks of the blockchain after this destruction.

Table 2 below summarizes the variation in actual and artificial resources in the above example.

orchestrator VMM1 VMM2 Allocated resources effective artificial effective artificial effective artificial Genesis 0 256 128 0 128 0 Operation 1 (creation VM1) 64 192 64 64 128 0 Operation 2 (resizing VM1) 32 224 96 32 128 0 Operation 3 (VM1 migration) 32 224 128 0 96 32 Operation 4 (destruction VM1) 256 0 128 0 128 0

Table 2

When creating a virtual machine, the orchestrator can also specify the number of physical cores (also known as "virtual CPUs" or "virtual processors") allocated to said machine. This number of virtual processors is dynamically allocated by the VMM manager according to the instructions of the orchestrator.

Initially (genesis), 32 virtual processors are allocated to the system and distributed in a balanced manner between the virtualization server SV1 and the virtualization server SV2. The virtualization server SV1 and the virtualization server SV2 each hold, for example, 16 effective resources (16 virtual processors) managed by their respective manager VMM1 and VMM2, and the orchestrator

-33 holds 32 (16x2) artificial resources. The difference between the number of effective resources and the number of artificial resources is therefore zero.

Table 3 below illustrates, for the same scenario as that of Table 2, the variation of the effective and artificial resources relating to virtual processors.

orchestrator VMM1 VMM2 Allocated resources effective artificial effective artificial effective artificial Genesis 0 32 16 0 16 0 Operation 1 (creation VM1 and VM2) 16 16 8 8 8 8 Operation 2 (resizing VM1) 12 20 12 4 8 8 Operation 3 (VM1 migration) 16 16 16 0 4 12 Operation 4 (destruction VM1) 12 20 16 0 8 8

Table 3

Operation 1: two virtual machines VMi and VM2 are created respectively in the server SV1 and SV2. 8 virtual processors are allocated to each of these virtual machines. The ORCH orchestrator "sells" to each of the managers VMM1, VMM2, 8 artificial resources and "buys" them respectively 8 effective resources.

Operation 2: the orchestrator resizes the virtual machine VM1 by removing 4 virtual processors from it. The ORCH orchestrator "sells" 4 effective resources to the VMM1 manager and "buys" 4 artificial resources from him.

Operation 3: the virtual machine VM1 migrates to the server SV2. The ORCH orchestrator "sells" 4 effective resources to the VMM1 manager and "buys" 4 artificial resources from him. The ORCH orchestrator "sells" 4 artificial resources to the VMM2 manager and "buys" 4 effective resources from him.

Operation 4: the virtual machine VM1 is destroyed in the virtualization server SV2. The ORCH orchestrator "sells" 4 effective resources to the VMM2 manager and "buys" 4 artificial resources from him.

In addition, another type of resource that can be allocated to a virtual machine is bandwidth. Each virtual machine can use a fraction of the entire physical bandwidth allocated to a virtualization server.

Initially (genesis), a bandwidth of 10 Gbit / s (Giga Bits per second) is for example allocated to the network, 4 Gbit / s for the virtualization server SVi and 6 Gbit / s for the virtualization server SV2. Also, the SV1 virtualization server has 4 effective resources (corresponding to the 4 Gbit / s allocated to it) managed by the VMM1 manager and the SV2 virtualization server has 6 effective resources (corresponding to the 6 Gbit / s allocated to it) managed by the VMM2 manager. The orchestrator holds 10 (6 + 4) artificial resources. The difference between the number of effective resources and the number of artificial resources is therefore zero.

Table 4 below illustrates, for the same scenario as those in Tables 2 and 3, the variation in actual and artificial resources relating to bandwidth allocations.

orchestrator VMM1 VMM2 Allocated resources effective artificial effective artificial effective artificial Genesis 0 10 4 0 6 0 Operation 1 (creation VM1 and VM2) 6 4 0 4 4 2 Operation 2 (resizing VM1) 4 6 2 2 4 2 Operation 3 (VM1 migration) 6 4 4 0 2 4 Operation 4 (destruction VM1) 4 6 4 0 4 2

Table 4

Operation 1: two virtual machines VM1 and VM2 are created respectively in the server SV1 and SV2. 4 Gbit / s are allocated to the virtual machine VM1 and 2 Gbit / s are allocated to the virtual machine VM2. The ORCH orchestrator "sells" to the VMM1 manager 4 artificial resources and "buys" 4

-35 effective resources. The ORCH orchestrator "sells" 2 artificial resources to the VMM2 manager and "buys" 2 effective resources from him.

Operation 2: the orchestrator resizes the virtual machine VM1 by reducing its bandwidth to 2 Gbit / s. The ORCH orchestrator "sells" 2 effective resources to the VMM1 manager and "buys" 2 artificial resources from him.

Operation 3: the virtual machine VM1 migrates to the server SV2. The ORCH orchestrator "sells" 2 effective resources to the VMM1 manager and "buys" 2 artificial resources from him. The ORCH orchestrator "sells" 2 artificial resources to the VMM2 manager and "buys" 2 effective resources from him.

Operation 4: the virtual machine VM1 is destroyed in the virtualization server SV2. The ORCH orchestrator "sells" 2 effective resources to the VMM2 manager and "buys" 2 artificial resources from him.

The arrangement of the various elements and / or means and / or stages of the invention, in the embodiments described above, should not be understood as requiring such an arrangement in all implementations. In any event, it will be understood that various modifications can be made to these elements and / or means and / or stages, without departing from the spirit and scope of the invention. In particular :

- The IT resource management operation performed by a manager can involve several virtual machines.

- To further secure the authentication process, communications between the orchestrator and the VMOA and the VMM manager and the VMOA can be carried out through a computer network which is separate from the computer network through which the orchestrator communicates. and the manager.

Claims (19)

claims 1. Authentication system for IT resource management instructions comprising: - at least one virtualization server (SV) with IT resources and comprising: o at least one virtual machine (VMi, VM2, VM3) in which all or part of the computer resources are allocated, o a virtual machine manager (VMM) adapted to execute an operation for managing the computer resources of the virtualization server (SV) based on an orchestration instruction, - at least one orchestrator (ORCH) adapted to provide the orchestration instruction, characterized in that the system also comprises an authentication device (VMOA) adapted to execute an authentication operation of the instruction d orchestration provided by the orchestrator (ORCH), which authentication operation is performed before the manager (VMM) executes the management operation. 2. System according to claim 1, in which: - the orchestration instruction provided by the orchestrator (ORCH) is included in a request sent by said orchestrator to the authentication device (VMOA), - the orchestration instruction is only transmitted by the orchestrator (ORCH) to the manager (VMM) after the authentication device (VMOA) has executed the authentication operation and transmitted to the orchestrator a response of validation of authentication. 3. System according to one of claims 1 or 2, wherein - the instruction received by the manager (VMM) is included in a request sent by said manager to the authentication device (VMOA), - the manager (VMM) executes the management operation only after the authentication device (VMOA) has executed the authentication operation and transmitted to the manager an authentication validation response. 4. System according to one of claims 1 to 3, in which: - the orchestrator (ORCH) is identified by a unique identification data, - the manager (VMM) is identified by a unique identification data, - the authentication device (VMOA) comprises a database in which a table is associated associating the identification data of the orchestrator (ORCH) with the identification data of the manager (VMM). 5. System according to claim 4, in which: - the request received by the authentication device (VMOA) contains a data item identifying the orchestrator (ORCH) and a data item identifying the manager (VMM), - during the authentication operation, the authentication device (VMOA) interrogates the table to verify that the identification data contained in the request correspond to the identification data contained in the table, - the authentication device (VMOA) is adapted to generate and transmit the authentication validation response, on condition that the identification data contained in the request correspond to the identification data contained in the table. 6. System according to one of claims 4 or 5, in which: the table stored in the authentication device database (VMOA) is adapted to memorize the nature and quantity of the computer resources available in the virtualization server (SV), - the request received by the authentication device (VMOA) also contains information concerning: the nature of the management operation to be executed, the -38nature and quantity of IT resources necessary to carry out this management operation, - during the authentication operation, the authentication device (VMOA) executes a logical computer process for interrogating the table to verify that the nature and quantity of the computer resources available in the virtualization server (SV) allow carry out the operation of managing said IT resources, - the authentication device (VMOA) is suitable for generating and transmitting the authentication validation response, only on condition that the nature and quantity of the computer resources available in the virtualization server (SV) makes it possible to carry out the operation of managing said computer resources. 7. System according to one of the preceding claims, comprising: - a plurality of virtualization servers (SVi, ..., SV _n ) each having IT resources and each comprising: o at least one virtual machine in which all or part of the IT resources of the respective virtualization server are allocated, o at least one manager (VMMn-VMMi _m , ..., VMM _n i-VMM _np ) of virtual machine adapted to run an operation for managing the IT resources of the respective virtualization server as a function of an orchestration instruction, - one or more orchestrators (ORCHi, ..., ORCH _n ), each of said orchestrators being adapted to provide an orchestration instruction to at least one of the managers (VMMn-VMMi _m , ..., VMM _n i-VMM _np ) - the authentication device (VMOA) is adapted to execute an authentication operation for each orchestration instruction provided by the orchestrator (s) (ORCHi, ..., ORCH _n ). 8. The system as claimed in claim 1, in which the authentication device (VMOA) is composed of several authentication modules (VMOAorch, (VMOAvmm) integrated in the manager (VMM) and in the orchestrator (ORCH), each of said means. modules receiving the orchestration instruction provided by the orchestrator (ORCH) and executing the authentication operation of said instruction autonomously. 9. System according to claim 1, comprising: - a plurality of virtualization servers (SVi, ..., SV _n ) each having IT resources and each comprising: o at least one virtual machine in which all or part of the IT resources of the respective virtualization server are allocated, o at least one virtual machine manager (VMMu-VMM-im, ..., VMM _n i-VMM _np ) suitable for execute an operation for managing the IT resources of the respective virtualization server as a function of an orchestration instruction, - one or more orchestrators (ORCHi, ..., ORCHn), each of said orchestrators being adapted to provide an orchestration instruction to at least one of the managers (VMMu-VMM-im, VMM _n i-VMM _np ), - the authentication device (VMOA) consists of several authentication modules (VMOAorchi, VMOAoRCHn, VMOAvmmu, VMOAvmmiri, VMOAvMMn-i, VMOAvMMn _P ) integrated in the managers (VMMu-VMM-im, VMMni-VMM _np ) and / or in the orchestrator (s) (ORCHi, ..., ORCHn), - each orchestration instruction provided by the orchestrator (s) (ORCHi, ..., ORCHn) is received by each of the authentication modules (VMOAorchi, VMOAoRCHn, VMOAvmmu, VMOAvmmiri, VMOAvMMni, VMOAvMMn _P ), which modules each execute a authentication operation in response to receipt of said instruction. 10. System according to one of claims 8 or 9, in which: - each orchestration instruction provided by an orchestrator (ORCHi, ..., ORCHn) is received by each of the authentication modules (VMOAorchi, VMOAoRCHn, VMOAvMM-11, VMOAvMMIm, VMOAvMMnl, VMOAvMMnp), - each manager (VMMn-VMMi _m , ..., VMM _n i-VMM _np ) is suitable for executing a management operation only if at least a predetermined number of authentication modules (VMOAorchi, VMOAoRCHn, VMOAvmmu, VMOAvMM-im , VMOAvMMn-i, VMOAvMMnp) performed an orchestration instruction authentication operation and generated an authentication validation response. 11. System according to one of claims 8 to 10, in which the management operations are recorded in blocks of a database structured in blockchain, which database is distributed or duplicated in each of the authentication modules ( VMOAvmm, VMOAorchi, VMOAoRCHn, VMOAvmmu, VMOAvMMIm, VMOAvMMnl, VMOAvMMnp). 12. Method for authenticating instructions for managing computer resources of at least one virtualization server (SV), comprising steps consisting in: - provide an orchestration instruction, - Execute an IT resource management operation of the virtualization server (SV) as a function of an orchestration instruction received, characterized by the fact that said method further comprises a step consisting in executing an authentication operation of the orchestration instruction, which authentication operation is performed before the execution of the management operation. 13. Method according to claim 12, comprising steps consisting in: - include an orchestration instruction in a request, - transmit the request to several integrated authentication modules (VMOAorch, VMOAvmm): o in a manager (VMM) adapted to execute the management operation, o and in an orchestrator (ORCH) adapted to provide the orchestration instruction. - execute an authentication operation of the orchestration instruction included in the request, in each of the authentication modules (VMOAorch, VMOAvmm). 14. Method according to claim 12, comprising steps consisting in: - include an orchestration instruction in a request, - transmit the request to several authentication modules (VMOAorchi, VMOAoRCHn, VMOAvmmu, VMOAvMMim, VMOAvMMn-ι, VMOAvMMnp): o in several managers (VMMn-VMMi _m , ..., VMM _n i-VMM _np ) adapted to execute each of the management operations, o and / or in several orchestrators (ORCHi, ..., ORCH _n ) adapted to provide each an orchestration instruction, - execute an authentication operation of the orchestration instruction included in the request, in each of the authentication modules (VMOAorchi, VMOAoRCHn, VMOAvmmu, VMOAvMMim, VMOAvMMnl, VMOAvMMnp). 15. The method of claim 14, comprising performing a management operation if at least a predetermined number of authentication modules (VMOAorchi, VMOAoRCHn, VMOAvmmu, VMOAvmmiri, VMOAvMMnl, VMOAvMMnp) has executed an authentication operation and generated a authentication validation response. 16. Method according to one of claims 12 to 15, consisting in recording the management operations, in blocks of a database structured in blockchain. 17. The method as claimed in claim 16, comprising allocating effective resources and artificial resources to at least one orchestrator (ORCH) and to at least one virtualization server (SVi, SV2), so that: - the artificial resources that the virtualization server has (SV1, SV2) represent the IT resources that are actually allocated to it at a given time and / or the IT resources used by at least one of its current virtual machines (VM1, VM2) execution, - the artificial resources that the orchestrator has (ORCH) represent the computing resources that it is actually capable of allocating to the virtualization server (SV1, SV2) at a given time, - the effective resources that the virtualization server has (SV1, SV2) represent the IT resources that it is able to allocate to at least one of its virtual machines (VM1, VM2) at a given time, - the effective resources that the orchestrator has (ORCH) represent the IT resources used by at least one virtual machine (VM1, VM2) running the virtualization server (SV1, SV2). 18. The method of claim 17, wherein a management operation is performed by implementing an exchange of effective resources and artificial resources between the orchestrator (ORCH) and the virtualization server (SVi, SV ₂ ). 19. The method of claim 18, wherein a transfer of effective resources, respectively of artificial resources, from the orchestrator (ORCH) to the virtualization server (SV1, SV2) triggers a transfer of artificial resources, respectively of effective resources, from the virtualization server (SV1, SV2) to the orchestrator (ORCH).