2. Architecture Requirements ¶
Table of Contents ¶
2.1 Introduction ¶
This chapter will use the requirements defined in the overall Reference Model and only make additional entries in section 2.3 if there are additional requirements needed for this Reference Architecture.
2.1.1 Definitions ¶
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC2119 .
2.2 Reference Model Requirements ¶
The tables below contains the requirements from the Reference Model to cover the Basic and Network Intensive profiles. The table also includes a reference to the specification from Chapter 04 - Architecture Specification to ensure traceability.
To ensure alignment with the infrastructure profile catalogue, the following requirements are referenced through:
-
Those relating to Cloud Infrastructure Software Profiles
-
Those relating to Cloud Infrastructure Hardware Profiles
-
Those relating to Storage Extensions (S extension)
-
Those relating to Network Acceleration Extensions (A extension)
-
Those relating to Cloud Infrastructure Management
Note; where “(if offered)” is used in the Reference Model, this has been replaced with “Optional” in the table below in order to align with the RFC2119 wording.
2.2.1 Cloud Infrastructure Software Profile Capabilities ¶
|
R eference Model Section |
R eference |
Des cription |
Req uirement for Basic Profile |
Req uirement for Network I ntensive Profile |
Speci fication R eference |
|---|---|---|---|---|---|
|
e .cap.001 |
Max number of vCPU that can be assigned to a single Pod by the Cloud Infras tructure |
At least 16 (1) |
At least 16 (1) |
||
|
e .cap.002 |
Max memory in MB that can be assigned to a single Pod by the Cloud Infras tructure |
at least 32 GB(1) |
at least 32 GB(1) |
||
|
e .cap.003 |
Max storage in GB that can be assigned to a single Pod by the Cloud Infras tructure |
at least 320 GB(1) |
at least 320 GB(1) |
||
|
e .cap.004 |
Max number of co nnection points that can be assigned to a single Pod by the Cloud Infras tructure |
6 |
6 |
`ra2.n tw.003 < chapter0 4.md#45- networki ng-solut ions>`__ |
|
|
e .cap.005 |
Max storage in GB that can be attached / mounted to Pod by the Cloud Infras tructure |
Up to 16TB(2) |
Up to 16TB(2) |
||
|
e .cap.006 |
CPU pinning support |
Not required |
Must support |
` ra2 .k8s.009
r04.md#4 3-kubern etes>`__ |
|
|
e .cap.007 |
NUMA support |
Not required |
Must support |
` ra2 .k8s.006
r04.md#4 3-kubern etes>`__ |
|
|
e .cap.008 |
IPSec Acce leration using the virt io-ipsec i nterface |
Not required |
Optional |
||
|
e .cap.009 |
Crypto Acce leration using the virti o-crypto i nterface |
Not required |
Optional |
||
|
e .cap.010 |
Tra nscoding Acce leration |
Not required |
Not required |
||
|
e .cap.011 |
Prog rammable Acce leration |
Not required |
Not required |
||
|
e .cap.012 |
Enhanced Cache Man agement: L=Lean; E=Equal; X= eXpanded |
E |
E |
||
|
e .cap.013 |
SR-IOV over PCI-PT |
Not required |
Must support |
ra2.ch. 002 `ra2 .ch.003 <chapter 04.md#42 -kuberne tes-node >`__ `ra2.k8s .007 <ch apter04. md#43-ku bernetes >`__ ra2.ntw .004 `ra2.n tw.008 < chapter0 4.md#45- networki ng-solut ions>`__ |
|
|
e .cap.014 |
Hardware cop rocessor support ( GPU/NPU) |
Not required |
Not required |
N/A |
|
|
e .cap.015 |
S martNICs |
Not required |
Optional |
||
|
e .cap.016 |
FP GA/other Acce leration H/W |
Not required |
Optional |
`ra2.k 8s.007 < chapter0 4.md#43- kubernet es>`__ `ra2.n tw.012 < chapter0 4.md#45- networki ng-solut ions>`__ |
|
|
e. cap.017 |
Ability to monitor L2-L7 data from w orkload |
n/a(3) |
n/a(3) |
||
|
i .cap.014 |
S pecifies the pr oportion of CPU cores consumed by the Cloud Infras tructure system on the worker nodes. If SMT is used, it i ndicates the number of consumed SMT threads. |
2 |
2 |
` ra2 .k8s.008
r04.md#4 3-kubern etes>`__ |
|
|
i .cap.015 |
I ndicates the memory consumed by Cloud Infras tructure on the worker nodes |
16 GB |
16GB |
||
|
i .cap.016 |
Number of virtual cores per physical core; also known as CPU ove rbooking ratio that is required |
1:1 |
1:1 |
`ra2 .ch.004 <chapter 04.md#42 -kuberne tes-node >`__ ra2.ch. 005 |
|
|
i .cap.017 |
QoS en ablement of the co nnection point (vNIC or in terface) |
Not required |
Must support |
||
|
i .cap.018 |
Support for huge pages |
Not required |
Must support |
||
|
i.pm.001 |
Monitor worker node CPU usage, per na nosecond |
Must support |
Must support |
||
|
i.pm.002 |
Monitor pod CPU usage, per na nosecond |
Must support |
Must support |
||
|
i.pm.003 |
Monitor worker node CPU uti lisation (%) |
Must support |
Must support |
||
|
i.pm.004 |
Monitor pod CPU uti lisation |
Must support |
Must support |
||
|
i.pm.005 |
Measure external storage IOPs |
Must support |
Must support |
||
|
i.pm.006 |
Measure external storage th roughput |
Must support |
Must support |
||
|
i.pm.007 |
Measure external storage capacity |
Must support |
Must support |
Table 2-1: Reference Model Requirements: Cloud Infrastructure Software Profile Capabilities
(1)
Defined in the
.4xlarge
flavour in section
4.2.1.1
Predefined Compute
Flavours
(2)
Defined in the
.bronze
configuration in section
4.2.3
Storage
Extensions
(3)
In Kubernetes based infrastructures packet monitoring is out of
the scope for the infrastructure.
2.2.2 Virtual Network Interface Specifications ¶
The required number of connection points to a Pod is described in
e.cap.004
above. This section describes the required bandwidth of
those connection points.
|
R eference Model Section |
R eference |
Des cription |
Req uirement for Basic Profile |
Req uirement for Network I ntensive Profile |
Speci fication R eference |
|---|---|---|---|---|---|
|
` 4.2.2 <. ./../../ ref_mode l/chapte rs/chapt er04.md# 422-virt ual-netw ork-inte rface-sp ecificat ions>`__ |
n1, n2, n3, n4, n5, n6 |
1, 2, 3, 4, 5, 6 Gbps |
Must support |
Must support |
|
|
` 4.2.2 <. ./../../ ref_mode l/chapte rs/chapt er04.md# 422-virt ual-netw ork-inte rface-sp ecificat ions>`__ |
nn10, n20, n30, n40, n50, n60 |
10, 20, 30, 40, 50, 60 Gbps |
Must support |
Must support |
|
|
` 4.2.2 <. ./../../ ref_mode l/chapte rs/chapt er04.md# 422-virt ual-netw ork-inte rface-sp ecificat ions>`__ |
n25, n50, n75, n100, n125, n150 |
25, 50, 75, 100, 125, 150 Gbps |
Must support |
Must support |
|
|
` 4.2.2 <. ./../../ ref_mode l/chapte rs/chapt er04.md# 422-virt ual-netw ork-inte rface-sp ecificat ions>`__ |
nn50, n100, n150, n200, n250, n300 |
50, 100, 150, 200, 250, 300 Gbps |
Must support |
Must support |
|
|
` 4.2.2 <. ./../../ ref_mode l/chapte rs/chapt er04.md# 422-virt ual-netw ork-inte rface-sp ecificat ions>`__ |
n100, n200, n300, n400, n500, n600 |
100, 200, 300, 400, 500, 600 Gbps |
Must support |
Must support |
Table 2-2: Reference Model Requirements: Network Interface Specifications
2.2.3 Cloud Infrastructure Software Profile Requirements ¶
|
R eference Model Section |
R eference |
Des cription |
Req uirement for Basic Profile |
Req uirement for Network I ntensive Profile |
Speci fication R eference |
|---|---|---|---|---|---|
|
`5.2.1 < ../../.. /ref_mod el/chapt ers/chap ter05.md #521-vir tual-com pute>`__ |
i nfra.com .cfg.001 |
CPU al location ratio |
1:1 |
1:1 |
`ra2 .ch.005 <chapter 04.md#42 -kuberne tes-node >`__ ra2.ch. 006 |
|
`5.2.1 < ../../.. /ref_mod el/chapt ers/chap ter05.md #521-vir tual-com pute>`__ |
i nfra.com .cfg.002 |
NUMA a wareness |
Must support |
Must support |
` ra2 .k8s.006
r04.md#4 3-kubern etes>`__ |
|
`5.2.1 < ../../.. /ref_mod el/chapt ers/chap ter05.md #521-vir tual-com pute>`__ |
i nfra.com .cfg.003 |
CPU pinning ca pability |
Not required |
Must support |
` ra2 .k8s.009
r04.md#4 3-kubern etes>`__ |
|
`5.2.1 < ../../.. /ref_mod el/chapt ers/chap ter05.md #521-vir tual-com pute>`__ |
i nfra.com .cfg.004 |
Huge Pages |
Must support |
Must support |
|
|
`5.2.2 < ../../.. /ref_mod el/chapt ers/chap ter05.md #522-vir tual-sto rage>`__ |
i nfra.stg .cfg.002 |
Storage Block |
Must support |
Must support |
` ra2 .stg.004
r04.md#4 6-storag e-compon ents>`__ |
|
`5.2.2 < ../../.. /ref_mod el/chapt ers/chap ter05.md #522-vir tual-sto rage>`__ |
i nfra.stg .cfg.003 |
Storage with rep lication |
Not required |
Must support |
|
|
`5.2.2 < ../../.. /ref_mod el/chapt ers/chap ter05.md #522-vir tual-sto rage>`__ |
i nfra.stg .cfg.004 |
Storage with en cryption |
Must support |
Must support |
|
|
`5.2.2 < ../../.. /ref_mod el/chapt ers/chap ter05.md #522-vir tual-sto rage>`__ |
infra .stg.acc .cfg.001 |
Storage IOPS oriented |
Not required |
Must support |
|
|
`5.2.2 < ../../.. /ref_mod el/chapt ers/chap ter05.md #522-vir tual-sto rage>`__ |
infra .stg.acc .cfg.002 |
Storage capacity oriented |
Not required |
Not required |
|
|
i nfra.net .cfg.001 |
IO virtua lisation using v irtio1.1 |
Must su pport(1) |
Must su pport(1) |
||
|
i nfra.net .cfg.002 |
The overlay network encap sulation protocol needs to enable ECMP in the underlay to take a dvantage of the s cale-out features of the network fa bric.(2) |
Must support VXLAN, M PLSoUDP, GENEVE, other |
No req uirement sp ecified |
||
|
i nfra.net .cfg.003 |
Network Address Tra nslation |
Must support |
Must support |
||
|
i nfra.net .cfg.004 |
Security Groups |
Must support |
Must support |
||
|
i nfra.net .cfg.005 |
SFC support |
Not required |
Must support |
||
|
i nfra.net .cfg.006 |
Traffic patterns symmetry |
Must support |
Must support |
||
|
infra .net.acc .cfg.001 |
vSwitch opti misation |
Not required |
Must support DPDK(3) |
`ra2.n tw.010 < chapter0 4.md#45- networki ng-solut ions>`__ |
|
|
infra .net.acc .cfg.002 |
Support of HW offload |
Not required |
Must support SmartNic |
||
|
infra .net.acc .cfg.003 |
Crypto acce leration |
Not required |
Must support |
||
|
infra .net.acc .cfg.004 |
Crypto Acce leration I nterface |
Not required |
Must support |
Table 2-3: Reference Model Requirements: Cloud Infrastructure Software Profile Requirements
(1) Workload Transition Guidelines. might have other interfaces (such as SR-IOV VFs to be directly passed to a VM or a Pod) or NIC-specific drivers on guest machines transiently allowed until more mature solutions are available with an acceptable level of efficiency to support telecom workloads (for example regarding CPU and energy consumption). (2) In Kubernetes based infrastructures network separation is possible without an overlay (e.g.: with IPVLAN) (3) This feature is not applicable for Kubernetes based infrastructures due to lack of vSwitch however workloads need access to user space networking solutions.
2.2.4 Cloud Infrastructure Hardware Profile Requirements ¶
|
R eference Model Section |
R eference |
Des cription |
Req uirement for Basic Profile |
Req uirement for Network I ntensive Profile |
Speci fication R eference |
|---|---|---|---|---|---|
|
infr a.hw.cpu .cfg.001 |
Minimum number of CPU sockets |
2 |
2 |
||
|
infr a.hw.cpu .cfg.002 |
Minimum number of Cores per CPU |
20 |
20 |
||
|
infr a.hw.cpu .cfg.003 |
NUMA |
Not required |
Must support |
` ra2 .k8s.006
r04.md#4 3-kubern etes>`__ |
|
|
infr a.hw.cpu .cfg.004 |
Simu ltaneous Multithr eading/S ymmetric Multipr ocessing ( SMT/SMP) |
Must support |
Must support |
||
|
infr a.hw.cac .cfg.001 |
GPU |
Not required |
Not required |
||
|
infra.hw .stg.hdd .cfg.001 |
Local Storage HDD |
No req uirement sp ecified |
No req uirement sp ecified |
||
|
infra.hw .stg.ssd .cfg.002 |
Local Storage SSD |
Should support |
Should support |
||
|
infr a.hw.nic .cfg.001 |
Total Number of NIC Ports a vailable in the host |
4 |
4 |
||
|
infr a.hw.nic .cfg.002 |
Port speed s pecified in Gbps (minimum values) |
10 |
25 |
`ra2 .ch.014 <chapter 04.md#42 -kuberne tes-node >`__ ra2.ch. 015 |
|
|
infr a.hw.pci .cfg.001 |
Number of PCIe slots a vailable in the host |
8 |
8 |
||
|
infr a.hw.pci .cfg.002 |
PCIe speed |
Gen 3 |
Gen 3 |
||
|
infr a.hw.pci .cfg.003 |
PCIe Lanes |
8 |
8 |
||
|
infr a.hw.nac .cfg.001 |
Crypt ographic Acce leration |
Not required |
Optional |
||
|
infr a.hw.nac .cfg.002 |
A SmartNIC that is used to offload vSwitch funct ionality to hardware |
Not required |
Opt ional(1) |
||
|
infr a.hw.nac .cfg.003 |
Com pression |
No req uirement sp ecified |
No req uirement sp ecified |
Table 2-4: Reference Model Requirements: Cloud Infrastructure Hardware Profile Requirements
(1) There is no vSwitch in case of containers, but a SmartNIC can be used to offload any other network processing.
2.2.5 Cloud Infrastructure Management Requirements ¶
|
Reference Model Section |
Reference |
Description |
Requirement (common to all Profiles) |
Sp ecification Reference |
|---|---|---|---|---|
|
e.man.001 |
Capability to allocate virtual compute resources to a workload |
Must support |
||
|
e.man.002 |
Capability to allocate virtual storage resources to a workload |
Must support |
||
|
e.man.003 |
Capability to allocate virtual networking resources to a workload |
Must support |
||
|
e.man.004 |
Capability to isolate resources between tenants |
Must support |
||
|
e.man.005 |
Capability to manage workload software images |
Must support |
||
|
e.man.006 |
Capability to provide information related to allocated virtualised resources per tenant |
Must support |
||
|
e.man.007 |
Capability to notify state changes of allocated resources |
Must support |
||
|
e.man.008 |
Capability to collect and expose performance information on virtualised resources allocated |
Must support |
||
|
e.man.009 |
Capability to collect and notify fault information on virtualised resources |
Must support |
Table 2-5: Reference Model Requirements: Cloud Infrastructure Management Requirements
2.2.6 Cloud Infrastructure Security Requirements ¶
|
Reference Model Section |
Reference |
Requirement (common to all Profiles) |
Specification Reference |
|---|---|---|---|
|
sec.gen.001 |
The Platform must maintain the specified configuration. |
||
|
sec.gen.002 |
All systems part of Cloud Infrastructure must support password hardening as defined in CIS Password Policy Gui de . Hardening: CIS Password Policy Guide |
||
|
sec.gen.003 |
All servers part of Cloud Infrastructure must support a root of trust and secure boot. |
||
|
sec.gen.004 |
The Operating Systems of all the servers part of Cloud Infrastructure must be hardened by removing or disabling unnecessary services, applications and network protocols, configuring operating system user authentication, configuring resource controls, installing and configuring additional security controls where needed, and testing the security of the Operating System. (NIST SP 800-123) |
||
|
sec.gen.005 |
The Platform must support Operating System level access control |
||
|
sec.gen.006 |
The Platform must support Secure logging. Logging with root account must be prohibited when root privileges are not required. |
||
|
sec.gen.007 |
All servers part of Cloud Infrastructure must be Time synchronized with authenticated Time service. |
||
|
sec.gen.008 |
All servers part of Cloud Infrastructure must be regularly updated to address security v ulnerabilities. |
||
|
sec.gen.009 |
The Platform must support Software integrity protection and verification and must scan source code and manifests. |
||
|
sec.gen.010 |
The Cloud Infrastructure must support encrypted storage, for example, block, object and file storage, with access to encryption keys restricted based on a need to know. Controlled Access Based on the Need to Know |
||
|
sec.gen.011 |
The Cloud Infrastructure should support Read and Write only storage partitions (write only permission to one or more authorized actors). |
||
|
sec.gen.012 |
The Operator must ensure that only authorized actors have physical access to the underlying infrastructure. |
||
|
sec.gen.013 |
The Platform must ensure that only authorized actors have logical access to the underlying infrastructure. |
||
|
sec.gen.014 |
All servers part of Cloud Infrastructure should support measured boot and an attestation server that monitors the measurements of the servers. |
||
|
sec.gen.015 |
Any change to the Platform must be logged as a security event, and the logged event must include the identity of the entity making the change, the change, the date and the time of the change. |
||
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.001 |
The Platform must support authenticated and secure access to API, GUI and command line interfaces. |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.002 |
The Platform must support Traffic Filtering for workloads (for example, Fire Wall). |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.003 |
The Platform must support Secure and encrypted communications, and confidentiality and integrity of network traffic. |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.004 |
The Cloud Infrastructure must support authentication, integrity and confidentiality on all network channels. |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.005 |
The Cloud Infrastructure must segregate the underlay and overlay networks. |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.006 |
The Cloud Infrastructure must be able to utilize the Cloud Infrastructure Manager identity lifecycle management capabilities. |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.007 |
The Platform must implement controls enforcing separation of duties and privileges, least privilege use and least common mechanism (Role-Based Access Control). |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.008 |
The Platform must be able to assign the Entities that comprise the tenant networks to different trust domains. |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.009 |
The Platform must support creation of Trust Relationships between trust domains. |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.010 |
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. |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.011 |
The Platform must not reuse the same authentication credential (e.g., key-pair) on different Platform components (e.g., on different hosts, or different services). |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.012 |
The Platform must protect all secrets by using strong encryption techniques, and storing the protected secrets externally from the component |
(e.g., in OpenStack Barbican). |
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.013 |
The Platform must provide secrets dynamically as and when needed. |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.014 |
The Platform should use Linux Security Modules such as SELinux to control access to resources. |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.015 |
The Platform must not contain back door entries (unpublished access points, APIs, etc.). |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.016 |
Login access to the platform’s components must be through encrypted protocols such as SSH v2 or TLS v1.2 or higher. Note: Hardened jump servers isolated from external networks are recommended |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.017 |
The Platform must provide the capability of using digital certificates that comply with X.509 standards issued by a trusted Certification Authority. |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.018 |
The Platform must provide the capability of allowing certificate renewal and revocation. |
|
|
` 7.9.2 <../../.. /ref_model/chap ters/chapter07. md#792-platform -and-access>`__ |
sec.sys.019 |
The Platform must provide the capability of testing the validity of a digital certificate (CA signature, validity period, non revocation, identity). |
|
|
sec.ci.001 |
The Platform must support Confidentiality and Integrity of data at rest and in-transit. |
||
|
sec.ci.002 |
The Platform should support self-encrypting storage devices. |
||
|
sec.ci.003 |
The Platform must support Confidentiality and Integrity of data related metadata. |
||
|
sec.ci.004 |
The Platform must support Confidentiality of processes and restrict information sharing with only the process owner (e.g., tenant). |
||
|
sec.ci.005 |
The Platform must support Confidentiality and Integrity of process-related metadata and restrict information sharing with only the process owner (e.g., tenant). |
||
|
sec.ci.006 |
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). |
||
|
sec.ci.007 |
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. |
||
|
sec.ci.008 |
The Cloud Infrastructure must support tenant networks segregation. |
||
|
sec.wl.001 |
The Platform must support Workload placement policy. |
||
|
sec.wl.002 |
The Cloud Infrastructure must provide methods to ensure the platform’s trust status and integrity (e.g. remote attestation, Trusted Platform Module). |
||
|
sec.wl.003 |
The Platform must support secure provisioning of workloads. |
||
|
sec.wl.004 |
The Platform must support Location assertion (for mandated in-country or location requirements). |
||
|
sec.wl.005 |
The Platform must support the separation of production and non-production Workloads. |
||
|
sec.wl.006 |
The Platform must support the separation of Workloads based on their categorisation (for example, payment card information, healthcare, etc.). |
||
|
sec.wl.007 |
The Operator should implement processes and tools to verify VNF authenticity and integrity. |
||
|
sec.img.001 |
Images from untrusted sources must not be used. |
||
|
sec.img.002 |
Images must be scanned to be maintained free from known v ulnerabilities. |
||
|
sec.img.003 |
Images must not be configured to run with privileges higher than the privileges of the actor authorized to run them. |
||
|
sec.img.004 |
Images must only be accessible to authorized actors. |
||
|
sec.img.005 |
Image Registries must only be accessible to authorized actors. |
||
|
sec.img.006 |
Image Registries must only be accessible over secure networks that enforce authentication, integrity and c onfidentiality. |
||
|
sec.img.007 |
Image registries must be clear of vulnerable and stale (out of date) versions. |
||
|
sec.lcm.001 |
The Platform must support Secure Provisioning, Availability, and Deprovisioning (Secure Clean-Up) of workload resources where Secure Clean-Up includes tear-down, defense against virus or other attacks. |
||
|
sec.lcm.002 |
Cloud operations staff and systems must use management protocols limiting security risk such as SNMPv3, SSH v2, ICMP, NTP, syslog and TLS v1.2 or higher. |
||
|
sec.lcm.003 |
The Cloud Operator must implement and strictly follow change management processes for Cloud Infrastructure, Cloud Infrastructure Manager and other components of the cloud, and Platform change control on hardware. |
||
|
sec.lcm.004 |
The Cloud Operator should support automated templated approved changes. |
||
|
sec.lcm.005 |
Platform must provide logs and these logs must be regularly monitored for anomalous behavior. |
||
|
sec.lcm.006 |
The Platform must verify the integrity of all Resource management requests. |
||
|
sec.lcm.007 |
The Platform must be able to update newly instantiated, suspended, hibernated, migrated and restarted images with current time information. |
||
|
sec.lcm.008 |
The Platform must be able to update newly instantiated, suspended, hibernated, migrated and restarted images with relevant DNS information. |
||
|
sec.lcm.009 |
The Platform must be able to update the tag of newly instantiated, suspended, hibernated, migrated and restarted images with relevant geolocation (geographical) information. |
||
|
sec.lcm.010 |
The Platform must log all changes to geolocation along with the mechanisms and sources of location information (i.e. GPS, IP block, and timing). |
||
|
sec.lcm.011 |
The Platform must implement Security life cycle management processes including the proactive update and patching of all deployed Cloud Infrastructure software. |
||
|
sec.lcm.012 |
The Platform must log any access privilege escalation. |
||
|
sec.mon.001 |
Platform must provide logs and these logs must be regularly monitored for events of interest. The logs must contain the following fields: event type, date/time, protocol, service or program used for access, s uccess/failure, login ID or process ID, IP address and ports (source and destination) involved. |
||
|
sec.mon.002 |
Security logs must be time synchronised. |
||
|
sec.mon.003 |
The Platform must log all changes to time server source, time, date and time zones. |
||
|
sec.mon.004 |
The Platform must secure and protect Audit logs (containing sensitive information) both in-transit and at rest. |
||
|
sec.mon.005 |
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. |
||
|
sec.mon.006 |
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 |
The Platform must Monitor and Audit security parameter configurations for compliance with defined security policies. |
||
|
sec.mon.008 |
The Platform must Monitor and Audit externally exposed interfaces for illegal access (attacks) and take corrective security hardening measures. |
||
|
sec.mon.009 |
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 |
The Platform must Monitor and Audit running processes to detect unexpected or unauthorized processes and take corrective actions accordingly. |
||
|
sec.mon.011 |
The Platform must Monitor and Audit logs from infrastructure elements and workloads to detected anomalies in the system components and take corrective actions accordingly. |
||
|
sec.mon.012 |
The Platform must Monitor and Audit Traffic patterns and volumes to prevent malware download attempts. |
||
|
sec.mon.013 |
The monitoring system must not affect the security (integrity and c onfidentiality) of the infrastructure, workloads, or the user data (through back door entries). |
||
|
sec.mon.014 |
The Monitoring systems should not impact IAAS, PAAS, and SAAS SLAs including availability SLAs. |
||
|
sec.mon.015 |
The Platform must ensure that the Monitoring systems are never starved of resources and must activate alarms when resource utilisation exceeds a configurable threshold. |
||
|
sec.mon.016 |
The Platform Monitoring components should follow security best practices for auditing, including secure logging and tracing. |
||
|
sec.mon.017 |
The Platform must audit systems for any missing security patches and take appropriate actions. |
||
|
sec.mon.018 |
The Platform, starting from initialization, must collect and analyze logs to identify security events, and store these events in an external system. |
||
|
sec.mon.019 |
The Platform’s components must not include an authentication credential, e.g., password, in any logs, even if encrypted. |
||
|
sec.mon.020 |
The Platform’s logging system must support the storage of security audit logs for a configurable period of time. |
||
|
sec.mon.021 |
The Platform must store security events locally if the external logging system is unavailable and shall periodically attempt to send these to the external logging system until successful. |
||
|
sec.std.001 |
The Cloud Operator should comply with Center for Internet Security CIS Controls ( h ttps://www.cise curity.org/ ) |
||
|
sec.std.002 |
The Cloud Operator, Platform and Workloads should follow the guidance in the CSA Security Guidance for Critical Areas of Focus in Cloud Computing (latest version) https://clouds ecurityalliance .org/ |
||
|
sec.std.003 |
The Platform and Workloads should follow the guidance in the OWASP Cheat Sheet Series (OCSS) `https://githu b.com/OWASP/Che atSheetSeries < https://github. com/OWASP/Cheat SheetSeries>`__ |
||
|
sec.std.004 |
The Cloud Operator, Platform and Workloads should ensure that their code is not vulnerable to the OWASP Top Ten Security Risks https:/ /owasp.org/www- project-top-ten / |
||
|
sec.std.005 |
The Cloud Operator, Platform and Workloads should strive to improve their maturity on the OWASP Software Maturity Model (SAMM) h ttps://owaspsam m.org/blog/2019 /12/20/version2 -community-rele ase/ |
||
|
sec.std.006 |
The Cloud Operator, Platform and Workloads should utilize the OWASP Web Security Testing Guide h ttps://github.c om/OWASP/wstg/t ree/master/docu ment |
||
|
sec.std.007 |
The Cloud Operator, and Platform should satisfy the requirements for Information Management Systems specified in ISO/IEC 27001 https:/ /www.iso.org/ob p/ui/#iso:std:i so-iec:27001:ed -2:v1:en . ISO/IEC 27002:2013 - ISO/IEC 27001 is the international Standard for best-practice information security management systems (ISMSs). |
||
|
sec.std.008 |
The Cloud Operator, and Platform should implement the Code of practice for Security Controls specified ISO/IEC 27002:2013 (or latest) https: //www.iso.org/o bp/ui/#iso:std: iso-iec:27002:e d-2:v1:en |
||
|
sec.std.009 |
The Cloud Operator, and Platform should implement the ISO/IEC 27032:2012 (or latest) Guidelines for Cybersecurity techniques https:/ /www.iso.org/ob p/ui/#iso:std:i so-iec:27032:ed -1:v1:en . ISO/IEC 27032 - ISO/IEC 27032is the international Standard focusing explicitly on cybersecurity. |
||
|
sec.std.010 |
The Cloud Operator should conform to the ISO/IEC 27035 standard for incidence management. ISO/IEC 27035 - ISO/IEC 27035 is the international Standard for incident management. |
||
|
sec.std.011 |
The Cloud Operator should conform to the ISO/IEC 27031 standard for business continuity. ISO/IEC 27031 - ISO/IEC 27031 is the international Standard for ICT readiness for business continuity. |
||
|
sec.std.012 |
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-6: Reference Model Requirements: Cloud Infrastructure Security Requirements
2.3 Kubernetes Architecture Requirements ¶
The Reference Model (RM) defines the Cloud Infrastructure, which consists of the physical resources, virtualised resources and a software management system. In the virtualised world, the Cloud Infrastructure consists of the Guest Operating System, Hypervisor and, if needed, other software such as libvirt. The Cloud Infrastructure Management component is responsible for, among others, tenant management, resources management, inventory, scheduling, and access management.
Now consider the containerisation equivalent, references to “Architecture” in this chapter refer to the Cloud Infrastructure Hardware (e.g. physical resources), Cloud Infrastructure Software (e.g. Hypervisor (optional), Container Runtime, virtual or container Orchestrator(s), Operating System), and infrastructure resources consumed by virtual machines or containers.
The requirements in this section are to be delivered in addition to those in section 2.2 , and have been created to support the Principles defined in Chapter 1 of this Reference Architecture .
|
Ref # |
Category |
S ub-category |
Description |
Sp ecification Reference |
|---|---|---|---|---|
|
|
General |
Cloud nativeness |
The A rchitecture must support immutable infr astructure. |
|
|
|
General |
Cloud nativeness |
The A rchitecture must run conformant Kubernetes as defined by the `CNCF < https://git hub.com/cnc f/k8s-confo rmance>`__ . |
|
|
|
General |
Cloud nativeness |
The A rchitecture must support clearly defined abstraction layers. |
|
|
|
General |
Cloud nativeness |
The A rchitecture should support co nfiguration of all components in an automated manner using openly published API d efinitions. |
|
|
|
General |
Scalability |
The A rchitecture should support policy driven horizontal a uto-scaling of workloads. |
|
|
|
General |
Resiliency |
The A rchitecture must support resilient Kubernetes components that are required for the continued a vailability of running workloads. |
|
|
|
General |
Resiliency |
The
A
rchitecture
should
support
resilient
Kubernetes
service
components
that are
not subject
to
|
|
|
|
General |
A vailability |
The A rchitecture must provide High A vailability for Kubernetes components. |
ra2.k8s .002 <chapt er04.md#43- kubernetes> `__`ra2 .k8s.003 ra2.k8s.00 4 |
|
|
General |
Openness |
The A rchitecture should embrace open-based standards and te chnologies. |
ra2.cr t.001 _ ra2.c rt.002 <cha pter04.md#4 4-container -runtimes> __ ra2. ntw.002 r a2.ntw.006
07 <chapter 04.md#45-ne tworking-so lutions>`__ |
|
|
Inf rastructure |
Compute |
The A rchitecture must provide compute resources for Pods. |
|
|
|
Inf rastructure |
Storage |
The A rchitecture must support the ability for an operator to choose whether or not to deploy persistent storage for Pods. |
|
|
|
Inf rastructure |
Network |
The A rchitecture must support network resiliency on the Kubernetes nodes. |
|
|
|
Inf rastructure |
Network |
The A rchitecture must support fully redundant network c onnectivity to the Kubernetes nodes, leveraging multiple network c onnections. |
|
|
|
Inf rastructure |
Network |
The networking solution should be able to be centrally ad ministrated and configured. |
04 <chapter 04.md#45-ne tworking-so lutions>`__ |
|
|
Inf rastructure |
Network |
The A rchitecture must support dual stack IPv4 and IPv6 for Kubernetes workloads. |
|
|
|
Inf rastructure |
Network |
The A rchitecture must support c apabilities for integrating SDN c ontrollers. |
|
|
|
Inf rastructure |
Network |
The A rchitecture must support more than one networking solution. |
07 <chapter 04.md#45-ne tworking-so lutions>`__ |
|
|
Inf rastructure |
Network |
The A rchitecture must support the ability for an operator to choose whether or not to deploy more than one networking solution. |
|
|
|
Inf rastructure |
Network |
The A rchitecture must provide a default network which implements the Kubernetes network model. |
|
|
|
Inf rastructure |
Network |
The networking solution must not interfere with or cause i nterference to any interface or network it does not own. |
|
|
|
Inf rastructure |
Network |
The A rchitecture must support Cluster wide c oordination of IP address assignment. |
|
|
|
Inf rastructure |
Network |
The platform must allow specifying multiple separate IP pools. Tenants are required to select at least one IP pool that is different from the control inf rastructure IP pool or other tenant IP pools. |
|
|
|
Inf rastructure |
Network |
The platform must allow NATless traffic (i.e. exposing the pod IP address directly to the outside), allowing source and destination IP addresses to be preserved in the traffic headers from workloads to external networks. This is needed e.g. for signaling ap plications, using SIP and Diameter protocols. |
|
|
|
Inf rastructure |
Virtual Inf rastructure |
The A rchitecture must support the capability for Containers to consume inf rastructure resources abstracted by Host Operating Systems that are running within a virtual machine. |
` ra2.ch.005 <chapter04. md#42-kuber netes-node> __`ra2 .ch.011 |
|
|
Inf rastructure |
Physical Inf rastructure |
The A rchitecture must support the capability for Containers to consume inf rastructure resources abstracted by Host Operating Systems that are running within a physical server. |
ra2.ch.008 |
|
|
Kubernetes Cluster |
General |
The A rchitecture must support policy driven horizontal a uto-scaling of Kubernetes Cluster. |
|
|
|
Kubernetes Cluster |
General |
The A rchitecture must enable workload resiliency. |
|
|
|
API |
General |
The A rchitecture must leverage the Kubernetes APIs to discover and de claratively manage compute (virtual and bare metal resources), network, and storage. |
For Networking: ra2.ntw.00 1
.008 <chapt er04.md#45- networking- solutions>` __ ra2. app.006 Comp ute/storage not yet met. |
|
|
API |
General |
The A rchitecture must support the usage of a Kubernetes Application package manager using the Kubernetes API, like Helm v3. |
|
|
|
API |
General |
The A rchitecture must support stable features in its APIs. |
|
|
|
API |
General |
The A rchitecture must support limited backward co mpatibility in its APIs. Support for the whole API must not be dropped, but the schema or other details can change. |
Table 2-7: Kubernetes Architecture Requirements