В сентябре 2014 года группой компаний — лидеров в производстве серверного оборудования было объявлено о планах заменить протокол управления аппаратными средствами, известный среди ИТ специалистов как Intelligent Platform Management Interface (IPMI). Новому протоколу дали имя Redfish.
По мнению разработчиков Redfish, используемый сейчас протокол уже устарел и не позволяет раскрыть весь потенциал управления современным ИТ-оборудованием. IPMI впервые был введён в 1998-м году при поддержке корпораций Intel, Dell, NEC и Hewlett-Packard. В то время серверы ещё управлялись 8-разрядными микроконтроллерами что существенно ограничивало протокол ещё на стадии разработки. В 2004-м году протокол был обновлён до версии 2.0. Основными усовершенствованиями, внесенными в IPMI 2.0, стали новые алгоритмы аутентификации и шифрования, новая функция Serial Over LAN (поддерживает удаленное взаимодействие с приложениями, BIOS и операционной системой), встроенный межсетевой экран и новые параметры конфигурации и регистрации пользователей. IPMI для злоумышленников является прекрасной возможностью получить средства для низкоуровневого доступа к серверу, не требующего средств операционной системы. Проблема безопасности усугубляется еще и тем, что немало IPMI-конфигураций являются доступными и без введения пароля или же используют пароль по умолчанию.
Кроме того, эксперты отметили, что пароли хранятся в открытом виде, отсутствует шифрование отдельных разновидностей IPMI-трафика, а утечка одного-единственного пароля означает полный доступ ко всем серверам группы.
Данные причины являются основными для создания нового протокола, отвечающего современным требованиям как в управлении системами, так и в плане безопасности.
Перед разработчиками Redfish стоит много различных задач по разработке архитектуры, протокола и модели представления данных. Предполагается, что данная архитектура будет поддерживать широкий спектр систем, эксплуатируемых сегодня — от автономных машин до стоек с оборудованием, используемых в облачной сфере. Простота в меру возможностей — ещё одна цель Redfish. Соответствие средам программирования, которые широко принимаются сегодня так же является одним из ключевых принципов.
1) интерфейс RESTful с использованием модели данных JSON;
2) протокол и модель данных разделены, что позволяет обновлять их отдельно друг от друга;
3) специальные правила задания версий для протокола и схемы;
4) устранение слабых мест в стандартах интернет-протоколов, в тех местах, где они сталкиваются с архитектурными требованиями, такими как JSON, HTTP и RFCs;
5) протокол сфокусирован на масштабируемых средах, но способен управлять текущими серверными средами;
6) фокус на out-of-band — осуществимымй в BMC и микропрограммных продуктах;
7) функционал должен быть доступным/понятным для среднестатистического пользователь;
8) реализация архитектуры должна быть максимально скрытная в целях безопасности.
1) даёт возможность лёгкой реализации в случаях, когда важна экономия (меньший объём передаваемых данных, чем у SOAP, меньше слоёв протокола, чем в WS-Man);
2) направлен на то, что бы стать самым распространённым методом доступа в промышленности;
3) прост в освоении, доступность документации;
4) есть ряд готовых инструментов и сред разработки, которые могут быть использованы для REST;
5) потребление RAM и СPU меньше, чем у других интерфейсов;
6) он поддерживает семантику модели данных и простое отображение общих операций CRUD;
7) соответствует принципу разработки: простота в пользовании;
8) он в равной мере может быть применён как во встроенных окружениях, так и в пространстве приложений, что даёт возможность сведения воедино кода компонентов в пределах экосистемы управления;
9) он изначально не привязан к схеме, благодаря чему хорошо адаптируется к любому языку моделирования;
10) благодаря ему Redfish возможно использовать для безопасного запуска механизмов в промышленности.
Версия протокола меняется крайне редко, в то время как версии модели данных могут по мере необходимости модифицироваться. Таким образом, в первую очередь ожидаются инновации в модели данных, а не в протоколе. Это позволит по мере необходимости изменять модель данных, не трогая версию API или протокола.
Все ресурсы могут быть выражены в фомате JSON. JSON Schema будет использоваться и расширена для определения классов. Как JSON, так и JSON Schema широко используются и имеют большое количество инструментов для разных языков программирования, которые ускоряют разработку.
В то время как большинство операций в этой архитектуре могут исполняться синхронно, некоторые операции могут занять слишком много времени на выполнение, больше чем клиент согласен ждать. По этой причине некоторые операции могут быть асинхронными по усмотрению службы. Запрос асинхронной операции ничем не отличается от запроса синхронной.
Использование кодов HTTP Response позволит клиенту определить, как была завершена операция: синхронно или асинхронно.
Операции могут быть разделены на два вида: внутренние и внешние. У протокола есть возможность поддерживать внешние операции — те операции, которые не отображаются свободно на CRUD. Примеры — обновление программного обеспечения или системный сброс. Обновление программного обеспечения рассматривается как три возможных операции: передача образа для обновления в систему, загрузка образа системой и его последующая активация. Возможно объединить эти операции в одно единственное действие или один вызов функции.
В Redfish эти внешние операции называются действиями. Есть определённые действия, заданные в схеме Redfish, которые описывают каждый ресурс. Для этих стандартных действий схема Redfish снабжена нормативным языком. Расширения ОЕМ также разрешены схемой и отнесены к действиям.
В данной архитектуре поддерживается большое разнообразие устройств и служб. Очень важной составляющей являются механизмы поддержки консоли, (KVM-IP), командной оболочки (например, командная строка Linux) и удалённого виртуального носителя. Их поддержка реализована в этом стандарте и выражена в схеме на уровне представления модели данных, однако сами протоколы выходят за рамки этого стандарта.
Проблема с безопасностью в удалённом интерфейсе, который является программируемым, состоит в том, чтобы обеспечить не только защиту передаваемых данных но и защиту самого интерфейса который используется для взаимодействия с Redfish. Тут подразумевается разработка надлежащих механизмов контроля безопасности на уровне интерфейсов и защита каналов обмена данных.
Реализации должны поддерживать TLS v1.1 или выше и использовать только совместимые соединения TLS для транспортировки конфиденциальных данных.
Реализации должны поддерживать AES-256, основанные на TLS. Redfish должны рассмотреть вопрос о поддержке шифров, которые включают проверку подлинности и идентификации без использования доверенных сертификатов: 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 является не только эффективным и безопасным, его аппаратные реализации могут достичь высоких скоростей при низкой стоимости и латентности.
Реализации должны поддерживать замену сертификата по умолчанию, если он предусмотрен, сертификатом, имеющим как минимум 4096 битный ключ RSA и RSA-SHA512 подпись.
1) модель привилегий для мониторинга и управления;
2) системные настройки;
3) конфигурация BIOS;
4) система управления питанием;
5) информационные датчики (мощности / тепловые / жизнеспособности);
6) настройки сети;
7) настройки памяти;
8) журналирование;
9) служба конфигурации Redfish;
10) управление учётными записями;
11) версии микропрограмм;
12) аутентификация внутри инфраструктуры;
13) совместимость с CURL;
14) Автоматизация клиентов;
15) встроенные служебные процессы.
По заявлениям разработчиков, Redfish будет обладать возможностю управлять не только одной системой но и целыми стеллажами систем. Также Redfish — это своего рода реинкарнация IPMI, и это означает, что при переходе на новую систему пользователь не потеряет ни одной из функций, за которые так полюбилась IPMI. Управление по дополнительному каналу дает возможность производить обслуживание независимо от работоспособности ОС. Он может быть использован для мониторинга или изменения настроек BIOS / UEFI, а также контролировать статистику на уровне системы: температура, напряжение, вентиляторы и источники питания. По свежайшим заявлениям создателей, стандарт находится в стадии разработки и вскоре будет представлен для анализа организации по промышленным стандартам.
По мнению разработчиков Redfish, используемый сейчас протокол уже устарел и не позволяет раскрыть весь потенциал управления современным ИТ-оборудованием. IPMI впервые был введён в 1998-м году при поддержке корпораций Intel, Dell, NEC и Hewlett-Packard. В то время серверы ещё управлялись 8-разрядными микроконтроллерами что существенно ограничивало протокол ещё на стадии разработки. В 2004-м году протокол был обновлён до версии 2.0. Основными усовершенствованиями, внесенными в IPMI 2.0, стали новые алгоритмы аутентификации и шифрования, новая функция Serial Over LAN (поддерживает удаленное взаимодействие с приложениями, BIOS и операционной системой), встроенный межсетевой экран и новые параметры конфигурации и регистрации пользователей. IPMI для злоумышленников является прекрасной возможностью получить средства для низкоуровневого доступа к серверу, не требующего средств операционной системы. Проблема безопасности усугубляется еще и тем, что немало IPMI-конфигураций являются доступными и без введения пароля или же используют пароль по умолчанию.
Кроме того, эксперты отметили, что пароли хранятся в открытом виде, отсутствует шифрование отдельных разновидностей IPMI-трафика, а утечка одного-единственного пароля означает полный доступ ко всем серверам группы.
Данные причины являются основными для создания нового протокола, отвечающего современным требованиям как в управлении системами, так и в плане безопасности.
Перед разработчиками Redfish стоит много различных задач по разработке архитектуры, протокола и модели представления данных. Предполагается, что данная архитектура будет поддерживать широкий спектр систем, эксплуатируемых сегодня — от автономных машин до стоек с оборудованием, используемых в облачной сфере. Простота в меру возможностей — ещё одна цель Redfish. Соответствие средам программирования, которые широко принимаются сегодня так же является одним из ключевых принципов.
Среди других принципов, заложенных при проектировании Redfish:
1) интерфейс RESTful с использованием модели данных JSON;
2) протокол и модель данных разделены, что позволяет обновлять их отдельно друг от друга;
3) специальные правила задания версий для протокола и схемы;
4) устранение слабых мест в стандартах интернет-протоколов, в тех местах, где они сталкиваются с архитектурными требованиями, такими как JSON, HTTP и RFCs;
5) протокол сфокусирован на масштабируемых средах, но способен управлять текущими серверными средами;
6) фокус на out-of-band — осуществимымй в BMC и микропрограммных продуктах;
7) функционал должен быть доступным/понятным для среднестатистического пользователь;
8) реализация архитектуры должна быть максимально скрытная в целях безопасности.
Основные причины для использования RESTful:
1) даёт возможность лёгкой реализации в случаях, когда важна экономия (меньший объём передаваемых данных, чем у SOAP, меньше слоёв протокола, чем в WS-Man);
2) направлен на то, что бы стать самым распространённым методом доступа в промышленности;
3) прост в освоении, доступность документации;
4) есть ряд готовых инструментов и сред разработки, которые могут быть использованы для REST;
5) потребление RAM и СPU меньше, чем у других интерфейсов;
6) он поддерживает семантику модели данных и простое отображение общих операций CRUD;
7) соответствует принципу разработки: простота в пользовании;
8) он в равной мере может быть применён как во встроенных окружениях, так и в пространстве приложений, что даёт возможность сведения воедино кода компонентов в пределах экосистемы управления;
9) он изначально не привязан к схеме, благодаря чему хорошо адаптируется к любому языку моделирования;
10) благодаря ему Redfish возможно использовать для безопасного запуска механизмов в промышленности.
Разделение протокола от модели данных
Версия протокола меняется крайне редко, в то время как версии модели данных могут по мере необходимости модифицироваться. Таким образом, в первую очередь ожидаются инновации в модели данных, а не в протоколе. Это позволит по мере необходимости изменять модель данных, не трогая версию API или протокола.
JSON
Все ресурсы могут быть выражены в фомате JSON. JSON Schema будет использоваться и расширена для определения классов. Как JSON, так и JSON Schema широко используются и имеют большое количество инструментов для разных языков программирования, которые ускоряют разработку.
Поддержка синхронных и асинхронных операций
В то время как большинство операций в этой архитектуре могут исполняться синхронно, некоторые операции могут занять слишком много времени на выполнение, больше чем клиент согласен ждать. По этой причине некоторые операции могут быть асинхронными по усмотрению службы. Запрос асинхронной операции ничем не отличается от запроса синхронной.
Использование кодов HTTP Response позволит клиенту определить, как была завершена операция: синхронно или асинхронно.
Действия
Операции могут быть разделены на два вида: внутренние и внешние. У протокола есть возможность поддерживать внешние операции — те операции, которые не отображаются свободно на CRUD. Примеры — обновление программного обеспечения или системный сброс. Обновление программного обеспечения рассматривается как три возможных операции: передача образа для обновления в систему, загрузка образа системой и его последующая активация. Возможно объединить эти операции в одно единственное действие или один вызов функции.
В Redfish эти внешние операции называются действиями. Есть определённые действия, заданные в схеме Redfish, которые описывают каждый ресурс. Для этих стандартных действий схема Redfish снабжена нормативным языком. Расширения ОЕМ также разрешены схемой и отнесены к действиям.
Поддержка устройств (консоль, KVM-IP, командная оболочка, виртуальные носители)
В данной архитектуре поддерживается большое разнообразие устройств и служб. Очень важной составляющей являются механизмы поддержки консоли, (KVM-IP), командной оболочки (например, командная строка Linux) и удалённого виртуального носителя. Их поддержка реализована в этом стандарте и выражена в схеме на уровне представления модели данных, однако сами протоколы выходят за рамки этого стандарта.
Проблема с безопасностью в удалённом интерфейсе, который является программируемым, состоит в том, чтобы обеспечить не только защиту передаваемых данных но и защиту самого интерфейса который используется для взаимодействия с Redfish. Тут подразумевается разработка надлежащих механизмов контроля безопасности на уровне интерфейсов и защита каналов обмена данных.
Безопасность
Реализации должны поддерживать TLS v1.1 или выше и использовать только совместимые соединения TLS для транспортировки конфиденциальных данных.
Реализации должны поддерживать AES-256, основанные на TLS. Redfish должны рассмотреть вопрос о поддержке шифров, которые включают проверку подлинности и идентификации без использования доверенных сертификатов: 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 является не только эффективным и безопасным, его аппаратные реализации могут достичь высоких скоростей при низкой стоимости и латентности.
Реализации должны поддерживать замену сертификата по умолчанию, если он предусмотрен, сертификатом, имеющим как минимум 4096 битный ключ RSA и RSA-SHA512 подпись.
Возможности Redfish
1) модель привилегий для мониторинга и управления;
2) системные настройки;
3) конфигурация BIOS;
4) система управления питанием;
5) информационные датчики (мощности / тепловые / жизнеспособности);
6) настройки сети;
7) настройки памяти;
8) журналирование;
9) служба конфигурации Redfish;
10) управление учётными записями;
11) версии микропрограмм;
12) аутентификация внутри инфраструктуры;
13) совместимость с CURL;
14) Автоматизация клиентов;
15) встроенные служебные процессы.
По заявлениям разработчиков, Redfish будет обладать возможностю управлять не только одной системой но и целыми стеллажами систем. Также Redfish — это своего рода реинкарнация IPMI, и это означает, что при переходе на новую систему пользователь не потеряет ни одной из функций, за которые так полюбилась IPMI. Управление по дополнительному каналу дает возможность производить обслуживание независимо от работоспособности ОС. Он может быть использован для мониторинга или изменения настроек BIOS / UEFI, а также контролировать статистику на уровне системы: температура, напряжение, вентиляторы и источники питания. По свежайшим заявлениям создателей, стандарт находится в стадии разработки и вскоре будет представлен для анализа организации по промышленным стандартам.
