Merge "Initial SPEC for SDO integration on Starlingx"
This commit is contained in:
commit
d65746627c
|
@ -0,0 +1,197 @@
|
|||
===================================
|
||||
StarlingX: Secure Device Onboarding
|
||||
===================================
|
||||
|
||||
Storyboard: https://storyboard.openstack.org/#!/story/2008117
|
||||
|
||||
This spec describes a new feature to enable secure Zero Touch
|
||||
Provisioning (ZTP) of SDO devices securely.
|
||||
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Secure Device Onboard(SDO) is an open source software that is in the process
|
||||
of becoming an industry standard through the FIDO alliance, which automates
|
||||
the process of securely onboarding SDO capable devices. By "onboard" we mean the
|
||||
process by which device establishes its first trusted connection with the
|
||||
device management service.
|
||||
|
||||
SDO brings in late binding, wherein the device owner can choose the Device
|
||||
management platform to which the device onboards just at or before comissioning
|
||||
of the device at the point of installation.
|
||||
|
||||
StarlingX needs to support deployments in environments that have a combination
|
||||
of compute systems ranging from small IOT devices to high compute Xeon platforms.
|
||||
Considering StarlingX is installed on some of these systems and requires to
|
||||
support the secure provisioning of the other non-StarlingX based devices,
|
||||
integrating/developing the SDO on Starlingx would add an additional capability
|
||||
to provision a non-Starlingx based devices.
|
||||
|
||||
The devices to be onboarded through SDO can be X-86/ARM based platform. Also, as
|
||||
earlier stated ranging from small compute IoT devices to higher compute Xeon
|
||||
devices. The only condition is that, the device must come with necessary
|
||||
credentials and SDO client software during the manufacturing stage.
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
|
||||
This proposal aims to support SDO onboarding capability on the StarlingX based
|
||||
platforms so that these systems can provision other devices that supports SDO.
|
||||
Thus ideally, the user deploying an SDO device would just power on it and
|
||||
connect to the network, whereupon the device would boot, connect itself to a
|
||||
StarlingX cloud and be fully provisioned by StarlingX SDO services and support
|
||||
in bringing up the device to fully functional state.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Overview of SDO and Integration on Starlingx
|
||||
--------------------------------------------
|
||||
|
||||
The SDO on-boarding process automates the secure provisioning of devices and it
|
||||
involves interactions between number of different entities that participate
|
||||
in the process. Those include: Manufacturer, Device, Owner, Rendezvous service,
|
||||
Device platform service.
|
||||
|
||||
We aim to enable SDO Rendezvous service and Device platform service on Starlingx
|
||||
kubernetes cluster.
|
||||
|
||||
The Device platform service provides the components for the device owner to
|
||||
integrate his choice of Device management service.
|
||||
|
||||
The device will be initialized with SDO special software load and security
|
||||
credentials created by utilizing the supply chain tools by the device manufacturer.
|
||||
Device's ownership vouchers will also be generated by the same tool, and then
|
||||
be feed into the Device platform service before going through the SDO process.
|
||||
|
||||
Device platform service synchronizes the voucher information with Rendezvous
|
||||
service which plays the role of directing the target device to the owner Device
|
||||
platfrom service.
|
||||
|
||||
Once the device powers on, It can establish a secure connection with the
|
||||
desired Device management service through standard SDO process. After that, the
|
||||
provision operation of the device node can be automatically performed.
|
||||
|
||||
The enabling of services are taken up in phases. The details of which are below:
|
||||
|
||||
* Phase One:
|
||||
Enable Rendezvous service as an application on Starlingx.
|
||||
|
||||
* Phase two:
|
||||
Enable the Device platform service on Starlingx.
|
||||
|
||||
This spec aims to close on Phase one details.
|
||||
|
||||
StarlingX support of SDO
|
||||
------------------------
|
||||
|
||||
There will be an Armada manifest and SDO helm charts for Rendezvous service,
|
||||
which will be uploaded and applied to pull the container images from a
|
||||
public registry, configure and launch the SDO services pods.
|
||||
|
||||
The SDO applications will be packaged as a tarball that can be transferred to
|
||||
the system and activated with system application-upload & system
|
||||
application-apply.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
None
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
TBD
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
TBD
|
||||
|
||||
Upgrade impact
|
||||
--------------
|
||||
|
||||
None
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
|
||||
* Poornima Y N
|
||||
|
||||
Repos Impacted
|
||||
--------------
|
||||
|
||||
* SDO-armada-app
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Create new repo for the new application 'SDO', define required armada
|
||||
manifests and import helm charts for app
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
* TBD
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Test cases will be developed for adding systems of various personalities and
|
||||
capabilities to the StarlingX cloud. Both positive and negative tests (e.g.
|
||||
tests with bad credentials which should be rejected) will be defined.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
We will add new documents for the SDO process.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
* Code: https://github.com/secure-device-onboard
|
||||
* Release: https://github.com/secure-device-onboard/release/releases/
|
||||
* Document: https://secure-device-onboard.github.io/docs/
|
||||
|
||||
|
||||
History
|
||||
=======
|
||||
|
||||
.. list-table:: Revisions
|
||||
:header-rows: 1
|
||||
|
||||
* - Release Name
|
||||
- Description
|
||||
* - STX 5.0
|
||||
- Introduced
|
Loading…
Reference in New Issue