Redfish - IPMI alternative is around the corner.
In September 2014, a group of leading companies in the production of server hardware announced plans to replace the hardware management protocol, known among IT specialists as the Intelligent Platform Management Management Interface (IPMI). The new protocol was given the name Redfish.
According to the developers of Redfish, the protocol used now is already outdated and does not allow unleashing the full potential of managing modern IT equipment. IPMI was first introduced in 1998 with the support of Intel, Dell, NEC and Hewlett-Packard. At that time, the servers were still controlled by 8-bit microcontrollers, which significantly limited the protocol at the development stage. In 2004, the protocol was updated to version 2.0. The main improvements introduced in IPMI 2.0 are the new authentication and encryption algorithms, the new Serial Over LAN feature (supports remote interaction with applications, the BIOS and the operating system), the built-in firewall, and new configuration and user registration settings. IPMI for attackers is an excellent opportunity to get the means for low-level access to a server that does not require the operating system tools. The security problem is further aggravated by the fact that quite a few IPMI configurations are available without entering a password or using the default password.
In addition, the experts noted that the passwords are stored in clear text, there is no encryption of certain types of IPMI traffic, and the leakage of a single password means full access to all servers of the group.
')
These reasons are fundamental to the creation of a new protocol that meets modern requirements both in system management and in terms of security.
Redfish developers have many different tasks to develop the architecture, protocol, and data representation model. It is assumed that this architecture will support a wide range of systems used today - from autonomous machines to racks with equipment used in the cloud sphere. Simplicity to the best of opportunities is another Redfish goal. Compliance with programming environments that are widely accepted today is also one of the key principles.
1) RESTful interface using JSON data model;
2) the protocol and data model are separated, which allows updating them separately from each other;
3) special rules for specifying versions for the protocol and scheme;
4) the elimination of weaknesses in the standards of Internet protocols, in those places where they are faced with architectural requirements, such as JSON, HTTP and RFCs;
5) the protocol is focused on scalable environments, but is capable of managing current server environments;
6) focus on out-of-band — feasible in the BMC and firmware;
7) the functionality should be accessible / understandable for the average user;
8) the implementation of the architecture should be as secretive as possible for security purposes.
1) allows easy implementation in cases where saving is important (less data transferred than SOAP, fewer protocol layers than WS-Man);
2) aims to become the most common access method in industry;
3) easy to learn, the availability of documentation;
4) there are a number of off-the-shelf development tools and environments that can be used for REST;
5) the consumption of RAM and PU is less than that of other interfaces;
6) it supports the semantics of the data model and a simple mapping of common CRUD operations;
7) corresponds to the principle of development: ease of use;
8) it can equally be applied both in embedded environments and in the application space, which makes it possible to bring together the code of components within the management ecosystem;
9) it is not initially tied to the scheme, so it is well adapted to any modeling language;
10) thanks to him it is possible to use Redfish for the safe launch of mechanisms in industry.
The protocol version changes extremely rarely, while the data model versions may be modified as necessary. Thus, first of all, innovations are expected in the data model, and not in the protocol. This will allow you to change the data model as needed, without touching the version of the API or protocol.
All resources can be expressed in JSON format. JSON Schema will be used and extended to define classes. Both JSON and JSON Schema are widely used and have a large number of tools for different programming languages that speed development.
While most operations in this architecture can be executed synchronously, some operations may take too long to complete, more than the client agrees to wait. For this reason, some operations may be asynchronous at the discretion of the service. A request for an asynchronous operation is no different from a synchronous request.
Using HTTP Response codes will allow the client to determine how the operation was completed: synchronously or asynchronously.
Operations can be divided into two types: internal and external. The protocol has the ability to support external operations - those operations that are not displayed freely on the CRUD. Examples are software update or system reset. A software update is considered as three possible operations: transferring the image for updating to the system, loading the image by the system and its subsequent activation. It is possible to combine these operations into one single action or one function call.
In Redfish, these external operations are called actions. There are certain actions defined in the Redfish scheme that describe each resource. For these standard actions, the Redfish scheme is provided with the normative language. OEM extensions are also allowed by the schema and assigned to actions.
This architecture supports a wide variety of devices and services. A very important component is the console support mechanisms, (KVM-IP), the command shell (for example, the Linux command line) and remote virtual media. Their support is implemented in this standard and is expressed in the scheme at the level of presentation of the data model, but the protocols themselves are beyond the scope of this standard.
The problem with security in a remote interface, which is programmable, is to ensure not only the protection of the transmitted data but also the protection of the interface itself that is used to interact with Redfish. This implies the development of appropriate security control mechanisms at the interface level and the protection of data exchange channels.
Implementations must support TLS v1.1 or higher and use only compatible TLS connections to transport sensitive data.
Implementations must support AES-256 based on TLS. Redfish should consider supporting ciphers that include authentication and identification without using trusted certificates: TLS_PSK_WITH_AES_256_GCM_SHA384, TLS_DHE_PSK_WITH_AES_256_GCM_SHA384, TLS_RSA_PSK_WITH_AES_256_GCM_SHA384
AES-GCM is not only efficient and secure, its hardware implementations can achieve high speeds at low cost and latency.
Implementations must support the replacement of the default certificate, if it is provided, with a certificate that has at least 4096 RSA key and RSA-SHA512 signature.
1) privilege model for monitoring and management;
2) system settings;
3) BIOS configuration;
4) power management system;
5) information sensors (power / heat / viability);
6) network settings;
7) memory settings;
8) journaling;
9) Redfish Configuration Service;
10) account management;
11) firmware versions;
12) authentication within the infrastructure;
13) compatibility with CURL;
14) Customer Automation;
15) built-in service processes.
According to the developers, Redfish will have the ability to manage not only one system but also entire racks of systems. Redfish is also a kind of IPMI reincarnation, and this means that when switching to a new system, the user will not lose any of the functions for which IPMI is so fond of. Management of an additional channel allows you to perform maintenance regardless of the OS. It can be used to monitor or change BIOS / UEFI settings, as well as monitor system-wide statistics: temperature, voltage, fans, and power supplies. According to the most recent statements by the creators, the standard is under development and will soon be submitted for analysis by an industry standards organization.
According to the developers of Redfish, the protocol used now is already outdated and does not allow unleashing the full potential of managing modern IT equipment. IPMI was first introduced in 1998 with the support of Intel, Dell, NEC and Hewlett-Packard. At that time, the servers were still controlled by 8-bit microcontrollers, which significantly limited the protocol at the development stage. In 2004, the protocol was updated to version 2.0. The main improvements introduced in IPMI 2.0 are the new authentication and encryption algorithms, the new Serial Over LAN feature (supports remote interaction with applications, the BIOS and the operating system), the built-in firewall, and new configuration and user registration settings. IPMI for attackers is an excellent opportunity to get the means for low-level access to a server that does not require the operating system tools. The security problem is further aggravated by the fact that quite a few IPMI configurations are available without entering a password or using the default password.
In addition, the experts noted that the passwords are stored in clear text, there is no encryption of certain types of IPMI traffic, and the leakage of a single password means full access to all servers of the group.
')
These reasons are fundamental to the creation of a new protocol that meets modern requirements both in system management and in terms of security.
Redfish developers have many different tasks to develop the architecture, protocol, and data representation model. It is assumed that this architecture will support a wide range of systems used today - from autonomous machines to racks with equipment used in the cloud sphere. Simplicity to the best of opportunities is another Redfish goal. Compliance with programming environments that are widely accepted today is also one of the key principles.
Among other principles laid out in the design of Redfish:
1) RESTful interface using JSON data model;
2) the protocol and data model are separated, which allows updating them separately from each other;
3) special rules for specifying versions for the protocol and scheme;
4) the elimination of weaknesses in the standards of Internet protocols, in those places where they are faced with architectural requirements, such as JSON, HTTP and RFCs;
5) the protocol is focused on scalable environments, but is capable of managing current server environments;
6) focus on out-of-band — feasible in the BMC and firmware;
7) the functionality should be accessible / understandable for the average user;
8) the implementation of the architecture should be as secretive as possible for security purposes.
The main reasons for using RESTful are:
1) allows easy implementation in cases where saving is important (less data transferred than SOAP, fewer protocol layers than WS-Man);
2) aims to become the most common access method in industry;
3) easy to learn, the availability of documentation;
4) there are a number of off-the-shelf development tools and environments that can be used for REST;
5) the consumption of RAM and PU is less than that of other interfaces;
6) it supports the semantics of the data model and a simple mapping of common CRUD operations;
7) corresponds to the principle of development: ease of use;
8) it can equally be applied both in embedded environments and in the application space, which makes it possible to bring together the code of components within the management ecosystem;
9) it is not initially tied to the scheme, so it is well adapted to any modeling language;
10) thanks to him it is possible to use Redfish for the safe launch of mechanisms in industry.
Protocol separation from data model
The protocol version changes extremely rarely, while the data model versions may be modified as necessary. Thus, first of all, innovations are expected in the data model, and not in the protocol. This will allow you to change the data model as needed, without touching the version of the API or protocol.
Json
All resources can be expressed in JSON format. JSON Schema will be used and extended to define classes. Both JSON and JSON Schema are widely used and have a large number of tools for different programming languages that speed development.
Support synchronous and asynchronous operations
While most operations in this architecture can be executed synchronously, some operations may take too long to complete, more than the client agrees to wait. For this reason, some operations may be asynchronous at the discretion of the service. A request for an asynchronous operation is no different from a synchronous request.
Using HTTP Response codes will allow the client to determine how the operation was completed: synchronously or asynchronously.
Actions
Operations can be divided into two types: internal and external. The protocol has the ability to support external operations - those operations that are not displayed freely on the CRUD. Examples are software update or system reset. A software update is considered as three possible operations: transferring the image for updating to the system, loading the image by the system and its subsequent activation. It is possible to combine these operations into one single action or one function call.
In Redfish, these external operations are called actions. There are certain actions defined in the Redfish scheme that describe each resource. For these standard actions, the Redfish scheme is provided with the normative language. OEM extensions are also allowed by the schema and assigned to actions.
Device support (console, KVM-IP, command shell, virtual media)
This architecture supports a wide variety of devices and services. A very important component is the console support mechanisms, (KVM-IP), the command shell (for example, the Linux command line) and remote virtual media. Their support is implemented in this standard and is expressed in the scheme at the level of presentation of the data model, but the protocols themselves are beyond the scope of this standard.
The problem with security in a remote interface, which is programmable, is to ensure not only the protection of the transmitted data but also the protection of the interface itself that is used to interact with Redfish. This implies the development of appropriate security control mechanisms at the interface level and the protection of data exchange channels.
Security
Implementations must support TLS v1.1 or higher and use only compatible TLS connections to transport sensitive data.
Implementations must support AES-256 based on TLS. Redfish should consider supporting ciphers that include authentication and identification without using trusted certificates: TLS_PSK_WITH_AES_256_GCM_SHA384, TLS_DHE_PSK_WITH_AES_256_GCM_SHA384, TLS_RSA_PSK_WITH_AES_256_GCM_SHA384
AES-GCM is not only efficient and secure, its hardware implementations can achieve high speeds at low cost and latency.
Implementations must support the replacement of the default certificate, if it is provided, with a certificate that has at least 4096 RSA key and RSA-SHA512 signature.
Redfish features
1) privilege model for monitoring and management;
2) system settings;
3) BIOS configuration;
4) power management system;
5) information sensors (power / heat / viability);
6) network settings;
7) memory settings;
8) journaling;
9) Redfish Configuration Service;
10) account management;
11) firmware versions;
12) authentication within the infrastructure;
13) compatibility with CURL;
14) Customer Automation;
15) built-in service processes.
According to the developers, Redfish will have the ability to manage not only one system but also entire racks of systems. Redfish is also a kind of IPMI reincarnation, and this means that when switching to a new system, the user will not lose any of the functions for which IPMI is so fond of. Management of an additional channel allows you to perform maintenance regardless of the OS. It can be used to monitor or change BIOS / UEFI settings, as well as monitor system-wide statistics: temperature, voltage, fans, and power supplies. According to the most recent statements by the creators, the standard is under development and will soon be submitted for analysis by an industry standards organization.
Source: https://habr.com/ru/post/238743/
All Articles