Initial SPEC for SDO integration on Starlingx
Story: 2008117 Change-Id: I0f54a1876d3f5d767472e216c82d618e11b5b471 Signed-off-by: Poornima <poornima.y.n@intel.com>
This commit is contained in:
parent
5b3e10cb1c
commit
c586505521
@ -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
Block a user