2. Architecture Requirements

2.1 Introduction

must: Requirements that are marked as must are considered mandatory and must exist in the reference architecture and reflected in any implementation targeting this reference architecture. The same applies to must not.

should: Requirements that are marked as should are expected to be fulfilled by the reference architecture but it is up to each service provider to accept an implementation targeting this reference architecture that is not reflecting on any of those requirements. The same applies to should not.

RFC2119

may: Requirements that are marked as may are considered optional. The same applies to may not.

This chapter includes both "Requirements" that must be satisifed in an RA-1 conformant implementation and "Recommendations" that are optional for implementation.

2.2 Reference Model Requirements

Traceability to Reference Model.

2.3 Architecture and OpenStack Requirements

"Architecture" in this chapter refers to Cloud infrastructure (referred to as NFVI by ETSI) + VIM (as specified in Reference Model Chapter 3).

2.3.1 General Requirements

Ref #	sub-category	Description	Traceability
`req.gen.ost.01`	Open source	The Architecture must use OpenStack APIs.	RA-1 5.3
`req.gen.ost.02`	Open source	The Architecture must support dynamic request and configuration of virtual resources (compute, network, storage) through OpenStack APIs.	RA-1 5.3
`req.gen.rsl.01`	Resiliency	The Architecture must support resilient OpenStack components that are required for the continued availability of running workloads.
`req.gen.avl.01`	Availability	The Architecture must provide High Availability for OpenStack components.	RA-1 4.2 "Underlying Resources"

Table 2-1: General Requirements

2.3.2 Infrastructure Requirements

Ref #	sub-category	Description	Traceability
`req.inf.com.01`	Compute	The Architecture must provide compute resources for VM instances.	RA-1 3.3.1.4 "Cloud Workload Services"
`req.inf.com.04`	Compute	The Architecture must be able to support multiple CPU SKU options to support various infrastructure profiles (Basic and Network Intensive).	RA-1 4.4.1. "Support for Profiles and T-shirt instance types"
`req.inf.com.05`	Compute	The Architecture must support Hardware Platforms with NUMA capabilities.	RA-1 4.4.1. "Support for Profiles and T-shirt instance types"
`req.inf.com.06`	Compute	The Architecture must support CPU Pinning of the vCPUs of VM instance.	RA-1 4.4.1. "Support for Profiles and T-shirt instance types"
`req.inf.com.07`	Compute	The Architecture must support different hardware configurations to support various infrastructure profiles (Basic and Network Intensive).	RA-1 3.3.3. "Host aggregates providing resource pooling"
`req.inf.com.08`	Compute	The Architecture must support allocating certain number of host cores for all non-tenant workloads such as for OpenStack services. SMT threads can be allocated to individual OpenStack services or their components.	Dedicating host cores to certain workloads (e.g., OpenStack services). Please see example, "Configuring libvirt compute nodes for CPU pinning"
`req.inf.com.09`	Compute	The Architecture must ensure that the host cores assigned to non-tenant and tenant workloads are SMT aware: that is, a host core and its associated SMT threads are either all assigned to non-tenant workloads or all assigned to tenant workloads.	Achieved through configuring the "cpu_dedicated_set" and "cpu_shared_set" parameters in nova.conf correctly.
`req.inf.stg.01`	Storage	The Architecture must provide remote (not directly attached to the host) Block storage for VM Instances.	RA-1 3.4.2.3. "Storage"
`req.inf.stg.02`	Storage	The Architecture must provide Object storage for VM Instances. Operators may choose not to implement Object Storage but must be cognizant of the risk of "Compliant VNFs" failing in their environment.	OpenStack Swift Service (RA-1 4.3.1.4 "Swift")
`req.inf.ntw.01`	Network	The Architecture must provide virtual network interfaces to VM instances.	RA-1 5.2.5. "Neutron"
`req.inf.ntw.02`	Network	The Architecture must include capabilities for integrating SDN controllers to support provisioning of network services, from the OpenStack Neutron service, such as networking of VTEPs to the Border Edge based VRFs.	RA-1 3.2.5. "Virtual Networking – 3rd party SDN solution"
`req.inf.ntw.03`	Network	The Architecture must support low latency and high throughput traffic needs.	RA-1 4.2.3. "Network Fabric"
`req.inf.ntw.05`	Network	The Architecture must allow for East/West tenant traffic within the cloud (via tunnelled encapsulation overlay such as VXLAN or Geneve).	RA-1 4.2.3. "Network Fabric"
`req.inf.ntw.07`	Network	The Architecture must support network resiliency.	RA-1 3.4.2.2. "Network"
`req.inf.ntw.10`	Network	The Cloud Infrastructure Network Fabric must be capable of enabling highly available (Five 9’s or better) Cloud Infrastructure.	RA-1 3.4.2.2. "Network"
`req.inf.ntw.15`	Network	The Architecture must support multiple networking options for Cloud Infrastructure to support various infrastructure profiles (Basic and Network Intensive).	RA-1 4.2.3.4. "Neutron ML2-plugin Integration" and "OpenStack Neutron Plugins"
`req.inf.ntw.16`	Network	The Architecture must support dual stack IPv4 and IPv6 for tenant networks and workloads.

Table 2-2: Infrastructure Requirements

2.3.3 VIM Requirements

Ref #	sub-category	Description	Traceability
`req.vim.01`	General	The Architecture must allow infrastructure resource sharing.	RA-1 3.2. "Consumable Infrastructure Resources and Services"
`req.vim.03`	General	The Architecture must allow VIM to discover and manage Cloud Infrastructure resources.	RA-1 5.2.7. "Placement"
`req.vim.05`	General	The Architecture must include image repository management.	RA-1 4.3.1.2. "Glance"
`req.vim.07`	General	The Architecture must support multi-tenancy.	RA-1 3.2.1. "Multi-Tenancy"
`req.vim.08`	General	The Architecture must support resource tagging.	"OpenStack Resource Tags"

Table 2-3: VIM Requirements

2.3.4 Interfaces & APIs Requirements

Ref #	sub-category	Description	Traceability
`req.int.api.01`	API	The Architecture must provide APIs to access the authentication service and the associated mandatory features detailed in chapter 5.	RA-1 5.2.1 "Keystone"
`req.int.api.02`	API	The Architecture must provide APIs to access the image management service and the associated mandatory features detailed in chapter 5.	RA-1 5.2.2 "Glance"
`req.int.api.03`	API	The Architecture must provide APIs to access the block storage management service and the associated mandatory features detailed in chapter 5.	RA-1 5.2.3 "Cinder"
`req.int.api.04`	API	The Architecture must provide APIs to access the object storage management service and the associated mandatory features detailed in chapter 5.	RA-1 5.2.4 "Swift"
`req.int.api.05`	API	The Architecture must provide APIs to access the network management service and the associated mandatory features detailed in chapter 5.	RA-1 5.2.5 "Neutron"
`req.int.api.06`	API	The Architecture must provide APIs to access the compute resources management service and the associated mandatory features detailed in chapter 5.	RA-1 5.2.6 "Nova"
`req.int.api.07`	API	The Architecture must provide GUI access tenant facing cloud platform core services.	RA-1 4.3.1.9 "Horizon"
`req.int.api.08`	API	The Architecture must provide APIs needed to discover and manage Cloud Infrastructure resources.	RA-1 5.2.7. "Placement"
`req.int.api.09`	API	The Architecture must provide APIs to access the orchestration service.	RA-1 5.2.8 "Heat"
`req.int.api.10`	API	The Architecture must expose the latest version and microversion of the APIs for the given CNTT OpenStack release for each of the OpenStack core services.	RA-1 5.2 Core OpenStack Services APIs

Table 2-4: Interfaces and APIs Requirements

2.3.5 Tenant Requirements

Ref #	sub-category	Description	Traceability
`req.tnt.gen.01`	General	The Architecture must support multi-tenancy.	duplicate of req.vim.07
`req.tnt.gen.02`	General	The Architecture must support self-service dashboard (GUI) and APIs for users to deploy, configure and manage their workloads.	RA-1 4.3.1.9 "Horizon" and 3.3.1.4 Cloud Workload Services

Table 2-5: Tenant Requirements

2.3.6 Operations and LCM

Ref #	sub-category	Description	Traceability
`req.lcm.gen.01`	General	The Architecture must support zero downtime expansion/change of physical capacity (compute hosts, storage increase/replacement).
`req.lcm.adp.02`	Automated deployment	The Architecture must support hitless upgrades of software provided by the cloud provider so that the availability of running workloads is not impacted.

Table 2-6: LCM Requirements

2.3.7 Assurance Requirements

Ref #	sub-category	Description
`req.asr.mon.01`	Integration	The Architecture must include integration with various infrastructure components to support collection of telemetry for assurance monitoring and network intelligence.
`req.asr.mon.03`	Monitoring	The Architecture must allow for the collection and dissemination of performance and fault information.
`req.asr.mon.04`	Network	The Cloud Infrastructure Network Fabric and Network Operating System must provide network operational visibility through alarming and streaming telemetry services for operational management, engineering planning, troubleshooting, and network performance optimisation.

Table 2-7: Assurance Requirements

2.3.8 Security Requirements

2.3.8.1. System Hardening

Ref #	sub-category	Description	Traceability
sec.gen.001	Hardening	The Platform must maintain the state to what it is specified to be and does not change unless through change management process.	RA-1 6.3.6 "Security LCM"
sec.gen.002	Hardening	All systems part of Cloud Infrastructure must support password hardening (strength and rules for updates (process), storage and transmission, etc.)
sec.gen.003	Hardening	All servers part of Cloud Infrastructure must support a root of trust and secure boot
sec.gen.004	Hardening	The Operating Systems of all the servers part of Cloud Infrastructure must be hardened
sec.gen.005	Hardening	The Platform must support Operating System level access control
sec.gen.006	Hardening	The Platform must support Secure logging	RA-1 6.3.2.5 "System Access"
sec.gen.007	Hardening	All servers part of Cloud Infrastructure must be Time synchronized with authenticated Time service
sec.gen.008	Hardening	All servers part of Cloud Infrastructure must be regularly updated to address security vulnerabilities
sec.gen.009	Hardening	The Platform must support Software integrity protection and verification
sec.gen.010	Hardening	The Cloud Infrastructure must support Secure storage (all types)
sec.gen.012	Hardening	The Operator must ensure that only authorized actors have physical access to the underlying infrastructure.
sec.gen.013	Hardening	The Platform must ensure that only authorized actors have logical access to the underlying infrastructure.

2.3.8.2. Platform and Access

Ref #	sub-category	Description	Traceability
sec.sys.001	Access	The Platform must support authenticated and secure access to API, GUI and command line interfaces	RA-1 6.3.1 "Platform Access"
sec.sys.002	Access	The Platform must support Traffic Filtering for workloads (for example, Fire Wall).	RA-1 6.3.1 "Platform Access"
sec.sys.003	Access	The Platform must support Secure and encrypted communications in order to ensure the confidentiality and integrity of network traffic.	RA-1 6.3.1 "Platform Access")
sec.sys.004	Access	The Cloud Infrastructure must support Secure network channels.	RA-1 6.3.1 "Platform Access"
sec.sys.005	Access	The Cloud Infrastructure must segregate the underlay and overlay networks.	RA-1 6.3.1 "Platform Access"
sec.sys.006	Access	The Cloud Infrastructure must be able to utilize the Cloud Infrastructure Manager identity management capabilities.	RA-1 6.3.1 "Identity"
sec.sys.007	Access	The Platform must implement controls enforcing least privilege use, such as Role-Based Access Control.	RA-1 6.3.1 "Platform Access"
sec.sys.008	Access	The Platform must be able to assign the Entities that comprise the tenant networks to different trust domains. (Communication between different trust domains is not allowed, by default.)	RA-1 6.3.1 "Platform Access"
sec.sys.009	Access	The Platform must support creation of Trust Relationships between trust domains. These maybe uni-directional relationships where the trusting domain trusts another domain (the “trusted domain”) to authenticate users for them or to allow access to its resources from the trusted domain. In a bidirectional relationship both domain are “trusting” and “trusted”.	RA-1 6.3.1 "Platform Access"
sec.sys.010	Access	For two or more domains without existing trust relationships, the Platform must not allow the effect of an attack on one domain to impact the other domains either directly or indirectly.	RA-1 6.3.1 "Platform Access"
sec.sys.011	Access	The Platform must not reuse the same authentication key-pair (for example, on different hosts, for different services)	RA-1 6.3.1 "Platform Access"
sec.sys.012	Access	The Platform must only use secrets encrypted using strong encryption techniques, and stored externally from the component (e.g., Barbican (OpenStack))	RA-1 6.3.1 "Platform Access"
sec.sys.013	Access	The Platform must generate secrets dynamically as and when needed.	RA-1 6.3.1 "Platform Access"

2.3.8.3. Confidentiality and Integrity

Ref #	sub-category	Description	Traceability
sec.ci.001	Confidentiality/Integrity	The Platform must support Confidentiality and Integrity of data at rest and in-transit	6.3.3 Confidentiality and Integrity
sec.ci.003	Confidentiality/Integrity	The Platform must support Confidentiality and Integrity of data related metadata	6.3.3 Confidentiality and Integrity
sec.ci.004	Confidentiality	The Platform must support Confidentiality of processes and restrict information sharing with only the process owner (e.g., tenant).	6.3.3 Confidentiality and Integrity
sec.ci.005	Confidentiality/Integrity	The Platform must support Confidentiality and Integrity of process-related metadata and restrict information sharing with only the process owner (e.g., tenant).	6.3.3 Confidentiality and Integrity
sec.ci.006	Confidentiality/Integrity	The Platform must support Confidentiality and Integrity of workload resource utilization (RAM, CPU, Storage, Network I/O, cache, hardware offload) and restrict information sharing with only the workload owner (e.g., tenant).	6.3.3 Confidentiality and Integrity
sec.ci.007	Confidentiality/Integrity	The Platform must not allow Memory Inspection by any actor other than the authorized actors for the Entity to which Memory is assigned (e.g., tenants owning the workload), for Lawful Inspection, and by secure monitoring services. Admin access must be carefully regulated	6.3.3 Confidentiality and Integrity
sec.ci.008	Confidentiality	The Cloud Infrastructure must support tenant networks segregation	6.3.3 Confidentiality and Integrity

2.3.8.4. Workload Security

Ref #	sub-category	Description	Traceability
sec.wl.001	Workload	The Platform must support Workload placement policy	6.3.4 Workload Security
sec.wl.002	Workload	The Platform must support operational security	6.3.4 Workload Security
sec.wl.003	Workload	The Platform must support secure provisioning of workloads	6.3.4 Workload Security
sec.wl.004	Workload	The Platform must support Location assertion (for mandated in-country or location requirements)	6.3.4 Workload Security
sec.wl.005	Workload	Production workloads must be separated from non-production workloads	6.3.4 Workload Security
sec.wl.006	Workload	Workloads must be separable by their categorisation (for example, payment card information, healthcare, etc.)	6.3.4 Workload Security

2.3.8.5. Image Security

Ref #	sub-category	Description	Traceability
sec.img.001	Image	Images from untrusted sources must not be used	RA-1 6.3.5 "Image Security"
sec.img.002	Image	Images must be maintained to be free from known vulnerabilities	RA-1 6.3.5 "Image Security"
sec.img.003	Image	Images must not be configured to run with privileges higher than the privileges of the actor authorized to run them
sec.img.004	Image	Images must only be accessible to authorized actors
sec.img.005	Image	Image Registries must only be accessible to authorized actors
sec.img.006	Image	Image Registries must only be accessible over secure networks
sec.img.007	Image	Image registries must be clear of vulnerable and stale (out of date) versions

2.3.8.6. Security LCM

Ref #	sub-category	Description	Traceability
sec.lcm.001	LCM	The Platform must support Secure Provisioning, Maintaining availability, Deprovisioning (secure Clean-Up) of workload resources; Secure clean-up: tear-down, defending against virus or other attacks, or observing of cryptographic or user service data	6.3.7 Security Audit Logging
sec.lcm.002	LCM	Operational must use management protocols limiting security risk such as SNMPv3, SSH v2, ICMP, NTP, syslog and TLS	6.3.7 Security Audit Logging
sec.lcm.003	LCM	The Cloud Operator must implement change management for Cloud Infrastructure, Cloud Infrastructure Manager and other components of the cloud; Platform change control on hardware	6.3.7 Security Audit Logging
sec.lcm.005	LCM	Platform must provide logs and these logs must be regularly scanned	6.3.7 Security Audit Logging
sec.lcm.006	LCM	The Platform must verify the integrity of all Resource management requests	6.3.7 Security Audit Logging
sec.lcm.007	LCM	The Platform must be able to update newly instantiated, suspended, hibernated, migrated and restarted images with current time information	6.3.7 Security Audit Logging
sec.lcm.008	LCM	The Platform must be able to update newly instantiated, suspended, hibernated, migrated and restarted images with relevant DNS information.	6.3.7 Security Audit Logging
sec.lcm.009	LCM	The Platform must be able to update the tag of newly instantiated, suspended, hibernated, migrated and restarted images with relevant geolocation (geographical) information	6.3.7 Security Audit Logging
sec.lcm.010	LCM	The Platform must log all changes to geolocation along with the mechanisms and sources of location information (i.e. GPS, IP block, and timing).	6.3.7 Security Audit Logging
sec.lcm.011	LCM	The Platform must implement Security life cycle management processes including proactively update and patch all deployed Cloud Infrastructure software.	6.3.7 Security Audit Logging

2.3.8.7. Monitoring and Security Audit

The Platform is assumed to provide configurable alerting and notification capability and the operator is assumed to have automated systems, policies and procedures to act on alerts and notifications in a timely fashion. In the following the monitoring and logging capabilities can trigger alerts and notifications for appropriate action.

Ref #	sub-category	Description	Traceability
sec.mon.001	Monitoring/Audit	Platform must provide logs and these logs must be regularly scanned for events of interest	RA-1 6.3.7.1 "Creating logs"
sec.mon.002	Monitoring	Security logs must be time synchronised
sec.mon.003	Monitoring	The Platform must log all changes to time server source, time, date and time zones
sec.mon.004	Audit	The Platform must secure and protect Audit logs (contain sensitive information) both in-transit and at rest
sec.mon.005	Monitoring/Audit	The Platform must Monitor and Audit various behaviours of connection and login attempts to detect access attacks and potential access attempts and take corrective actions accordingly	RA-1 6.3.7.2 "What to log, what not to log"
sec.mon.006	Monitoring/Audit	The Platform must Monitor and Audit operations by authorized account access after login to detect malicious operational activity and take corrective actions accordingly
sec.mon.007	Monitoring/Audit	The Platform must Monitor and Audit security parameter configurations for compliance with defined security policies
sec.mon.008	Monitoring/Audit	The Platform must Monitor and Audit externally exposed interfaces for illegal access (attacks) and take corrective security hardening measures
sec.mon.009	Monitoring/Audit	The Platform must Monitor and Audit service handling for various attacks (malformed messages, signalling flooding and replaying, etc.) and take corrective actions accordingly
sec.mon.010	Monitoring/Audit	The Platform must Monitor and Audit running processes to detect unexpected or unauthorized processes and take corrective actions accordingly
sec.mon.011	Monitoring/Audit	The Platform must Monitor and Audit logs from infrastructure elements and workloads to detected anomalies in the system components and take corrective actions accordingly	RA-1 6.3.7.1 "Creating logs"
sec.mon.012	Monitoring/Audit	The Platform must Monitor and Audit Traffic patterns and volumes to prevent malware download attempts
sec.mon.013	Monitoring	The monitoring system must not affect the security (integrity and confidentiality) of the infrastructure, workloads, or the user data (through back door entries).
sec.mon.015	Monitoring	The Platform must ensure that the Monitoring systems are never starved of resources
sec.lcm.017	Audit	The Platform must Audit systems for any missing security patches and take appropriate actions	RA-1 6.3.2.3 "Patches"

2.3.8.8. Compliance with Standards

Ref #	sub-category	Description	Traceability
sec.std.018	Standards	The Public Cloud Operator must, and the Private Cloud Operator may be certified to be compliant with the International Standard on Awareness Engagements (ISAE) 3402 (in the US: SSAE 16); International Standard on Awareness Engagements (ISAE) 3402. US Equivalent: SSAE16

Table 2-8: OpenStack Security Requirements.

2.4 Architecture and OpenStack Recommendations

The requirements listed in this section are optional, and are not required in order to be deemed a conformant implementation.

2.4.1 General Recommendations

Ref #	sub-category	Description	Notes
`req.gen.cnt.01`	Cloud nativeness	The Architecture should consist of stateless service components. However, where state is required it must be kept external to the component.	OpenStack consists of both stateless and stateful services where the stateful services utilize a database. For latter see "Configuring the stateful services"
`req.gen.cnt.02`	Cloud nativeness	The Architecture should consist of service components implemented as microservices that are individually dynamically scalable.
`req.gen.scl.01`	Scalability	The Architecture should support policy driven auto-scaling.	This requirement is currently not addressed but will likely be supported through Senlin, cluster management service.
`req.gen.rsl.02`	Resiliency	The Architecture should support resilient OpenStack service components that are not subject to `req.gen.rsl.01`.

Table 2-9: General Recommendations

2.4.2 Infrastructure Recommendations

Ref #	sub-category	Description	Notes
`req.inf.com.02`	Compute	The Architecture should include industry standard hardware management systems at both HW device level (embedded) and HW platform level (external to device).
`req.inf.com.03`	Compute	The Architecture should support Symmetric Multiprocessing with shared memory access as well as Simultaneous Multithreading.
`req.inf.stg.08`	Storage	The Architecture should allow use of externally provided large archival storage for its Backup / Restore / Archival needs.
`req.inf.stg.09`	Storage	The Architecture should make available all non-host OS / Hypervisor / Host systems storage as network-based Block, File or Object Storage for tenant/management consumption.
`req.inf.stg.10`	Storage	The Architecture should provide local Block storage for VM Instances.	RA-1 "Virtual Storage"
`req.inf.ntw.04`	Network	The Architecture should support service function chaining.
`req.inf.ntw.06`	Network	The Architecture should support Distributed Virtual Routing (DVR) to allow compute nodes to route traffic efficiently.
`req.inf.ntw.08`	Network	The Cloud Infrastructure Network Fabric should embrace the concepts of open networking and disaggregation using commodity networking hardware and disaggregated Network Operating Systems.
`req.inf.ntw.09`	Network	The Cloud Infrastructure Network Fabric should embrace open-based standards and technologies.
`req.inf.ntw.11`	Network	The Cloud Infrastructure Network Fabric should be architected to provide a standardised, scalable, and repeatable deployment model across all applicable Cloud Infrastructure sites.

`req.inf.ntw.17`	Network	The Architecture should use dual stack IPv4 and IPv6 for Cloud Infrastructure internal networks.
`req.inf.acc.01`	Acceleration	The Architecture should support Application Specific Acceleration (exposed to VNFs).	RA-1 3.2.6. "Acceleration"
`req.inf.acc.02`	Acceleration	The Architecture should support Cloud Infrastructure Acceleration (such as SmartNICs).	"OpenStack Future - Specs defined"
`req.inf.acc.03`	Acceleration	The Architecture should not rely on SR-IOV PCI-Pass through to provide acceleration to VNFs.
`req.inf.img.01`	Image	The Architecture should make the immutable images available via location independent means.	RA-1 4.3.1.2. "Glance"

Table 2-10: Infrastructure Recommendations

2.4.3 VIM Recommendations

Ref #	sub-category	Description	Notes
`req.vim.02`	General	The Architecture should support deployment of OpenStack components in containers.	RA-1 4.3.2. "Containerised OpenStack Services"
`req.vim.04`	General	The Architecture should support Enhanced Platform Awareness (EPA) only for discovery of infrastructure resource capabilities.
`req.vim.06`	General	The Architecture should allow orchestration solutions to be integrated with VIM.
`req.vim.09`	General	The Architecture should support horizontal scaling of OpenStack core services.

Table 2-11: VIM Recommendations

2.4.4 Interfaces and APIs Recommendations

Ref #	sub-category	Description	Notes
`req.int.acc.01`	Acceleration	The Architecture should provide an open and standard acceleration interface to VNFs.
`req.int.acc.02`	Acceleration	The Architecture should not rely on SR-IOV PCI-Pass through for acceleration interface exposed to VNFs.	duplicate of `req.inf.acc.03` under "Infrastructure Recommendations"

Table 2-12: Interfaces and APIs Recommendations

2.4.5 Tenant Recommendations

Ref #	sub-category	Description	Notes

Table 2-13: Tenant Recommendations

2.4.6 Operations and LCM Recommendations

Ref #	sub-category	Description
`req.lcm.adp.01`	Automated deployment	The Architecture should allow for “cookie cutter” automated deployment, configuration, provisioning and management of multiple Cloud Infrastructure sites.
`req.lcm.adp.03`	Automated deployment	The Architecture should support hitless upgrade of all software provided by the cloud provider that are not covered by `req.lcm.adp.02`. Whenever hitless upgrades are not feasible, attempt should be made to minimize the duration and nature of impact.
`req.lcm.adp.04`	Automated deployment	The Architecture should support declarative specifications of hardware and software assets for automated deployment, configuration, maintenance and management.
`req.lcm.adp.05`	Automated deployment	The Architecture should support automated process for Deployment and life-cycle management of VIM Instances.
`req.lcm.cid.02`	CI/CD	The Architecture should support integrating with CI/CD Toolchain for Cloud Infrastructure and VIM components Automation.

Table 2-14: LCM Recommendations

2.4.7 Assurance Recommendations

Ref #	sub-category	Description	Notes
`req.asr.mon.02`	Monitoring	The Architecture should support Network Intelligence capabilities that allow richer diagnostic capabilities which take as input broader set of data across the network and from VNF workloads.

Table 2-15: Assurance Recommendations

2.4.8 Security Recommendations

2.4.8.1. System Hardening

Ref #	sub-category	Description	Notes
sec.gen.011	Hardening	The Cloud Infrastructure should support Read and Write only storage partitions (write only permission to one or more authorized actors)
sec.gen.014	Hardening	All servers part of Cloud Infrastructure should support measured boot and an attestation server that monitors the measurements of the servers.

2.4.8.2. Platform and Access

Ref #	sub-category	Description	Notes

2.4.8.3. Confidentiality and Integrity

Ref #	sub-category	Description	Notes
sec.ci.002	Confidentiality/Integrity	The Platform should support self-encrypting storage devices

2.4.8.4. Workload Security

Ref #	sub-category	Description	Notes
sec.wl.007	Workload	The Operator should implement processes and tools to verify VNF authenticity and integrity.

2.4.8.5. Image Security

Ref #	sub-category	Description	Notes

2.4.8.6. Security LCM

Ref #	sub-category	Description	Notes
sec.lcm.004	LCM	The Cloud Operator should support automated templated approved changes; Templated approved changes for automation where available

2.4.8.7. Monitoring and Security Audit