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:
Poornima 2020-09-10 05:19:50 +05:30
parent 5b3e10cb1c
commit c586505521
1 changed files with 197 additions and 0 deletions

View File

@ -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