From 3bcca77d8de26948b5e0b554ad26d5863481a847 Mon Sep 17 00:00:00 2001 From: cah-patrickthiem Date: Thu, 14 Mar 2024 15:26:18 +0100 Subject: [PATCH 1/3] Initial standards draft document for IPv4 networking --- .../scs-xxxx-v1-ipv4-networking-standard.md | 71 +++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 Standards/scs-xxxx-v1-ipv4-networking-standard.md diff --git a/Standards/scs-xxxx-v1-ipv4-networking-standard.md b/Standards/scs-xxxx-v1-ipv4-networking-standard.md new file mode 100644 index 000000000..b2c7d4f5c --- /dev/null +++ b/Standards/scs-xxxx-v1-ipv4-networking-standard.md @@ -0,0 +1,71 @@ +--- +title: IPv4 Networking Standard +type: Standard +status: Proposal +track: IaaS +--- + +## Introduction + +This document outlines the standardized approach for the management and allocation of +public IPv4 addresses within Sovereign Cloud Stack (SCS) environments. Its aim is to +ensure a consistent, secure, and efficient methodology for IP address provisioning +across all SCS cloud services. + +## Motivation + +The motivation behind establishing this standard is to enhance interoperability, improve +security measures, and streamline the operational processes across different SCS clouds. +It addresses the need for a unified procedure in handling IPv4 networking to facilitate +ease of use for IaaS users and DevOps teams. + +## Design Considerations + +### Options considered + +#### _Option 1_ + +Usage of Neutron Routers: Neutron routers are mandated to manage traffic between +internal and external networks. They shall act as the default gateway for VMs +requiring access to external networks and the internet, thereby facilitating the +routing of traffic and enhancing network security. + +#### _Option 2_ + +Security Group Policies: Standardized security group policies shall be applied to all +instances utilizing public IPv4 addresses. These policies must define and enforce access +controls to ensure the security of the cloud environment. + +#### _Option 3_ +IP Usage Monitoring: SCS clouds must implement monitoring solutions to track the +utilization of IPv4 addresses. This facilitates efficient management of resources and +supports capacity planning efforts. + +#### _Option 4_ +External Network Naming: All SCS clouds must adopt the naming convention +scs-external-net for external networks. This standardization facilitates easier +identification and management of external network resources. + +#### _Option 5_ +Floating IPs for Dynamic Allocation: Utilize Floating IPs to allow dynamic reassignment +of public IPv4 addresses to different instances (VMs or Loadbalancers), facilitating +high availability and fault tolerance. + +## Open questions + +- Naming Convention Flexibility: How rigid should the naming convention for external +networks be across various SCS clouds? +- Security Policy Standardization: To what extent should security group policies be +standardized without impeding individual cloud providers' autonomy? + +## Decision + +... + +## Related Documents + +Related Documents, OPTIONAL + +## Conformance Tests + +Conformance Tests, OPTIONAL From a856c55be0219d6772cdd237a9599fae0e44816a Mon Sep 17 00:00:00 2001 From: cah-patrickthiem Date: Tue, 26 Mar 2024 18:32:58 +0100 Subject: [PATCH 2/3] Added more detailed standardization options regarding IPv4 networking and its components. --- .../scs-xxxx-v1-ipv4-networking-standard.md | 52 +++++++++++-------- 1 file changed, 30 insertions(+), 22 deletions(-) diff --git a/Standards/scs-xxxx-v1-ipv4-networking-standard.md b/Standards/scs-xxxx-v1-ipv4-networking-standard.md index b2c7d4f5c..163cbe07a 100644 --- a/Standards/scs-xxxx-v1-ipv4-networking-standard.md +++ b/Standards/scs-xxxx-v1-ipv4-networking-standard.md @@ -23,40 +23,48 @@ ease of use for IaaS users and DevOps teams. ### Options considered -#### _Option 1_ +#### _Neutron Routers_ -Usage of Neutron Routers: Neutron routers are mandated to manage traffic between -internal and external networks. They shall act as the default gateway for VMs -requiring access to external networks and the internet, thereby facilitating the -routing of traffic and enhancing network security. +Usage of Neutron Routers: To manage traffic between internal and external networks Neutron Routers **MUST** be used as the default gateway for VMs requiring access to external networks and the internet, thereby facilitating the routing of traffic and enhancing network security. -#### _Option 2_ +CSPs **SHOULD** use OVN or L3agent as High Availability (HA) service deployments. +Standard external networks **MUST NOT** be made accessible as _shared networks_. It is advised that external networks are only reachable by the usage of routing and floating IPs. +However, for special use cases like certain storage or VPN solutions it could be useful to allow _direct access networks_. -Security Group Policies: Standardized security group policies shall be applied to all -instances utilizing public IPv4 addresses. These policies must define and enforce access +External networks and subnets **SHOULD** (very strong should) be configured with _--no-dhcp_ (DHCP - Dynamic Host Configuration Protocol). It is more secure to configure it like this, since it gives less space for reflection attacks, e.g. _Denial of Service_ (DOS) attacks. If _dhcp_ is configured, certain firewall configurations **MUST** be made to catch IPs from the _Neutron dhcp agent_ in the public network. + +#### _Neutron Plugins_ + +Neutron Plugins: A SCS conform CSP **MAY** use RBAC and VPNaaS plugins. +(Neutron RBAC needs to be configured explicitly to be able to use it. If configured, Neutron configurations can be shared across OpenStack projects. It also can be beneficial for admins, since an admin could bind external networks only to certain projects.) + +#### _Security Groups_ + +Security Group Policies: Standardized security group policies **SHOULD** be applied to all instances utilizing public IPv4 addresses. These policies must define and enforce access controls to ensure the security of the cloud environment. +Security Groups **SHOULD** be enabled by default but **MUST** be capable of being switched off. + +#### _Quota & Monitoring_ + +Quota: The standard quota of floating IPs and routers **SHOULD** be rather small, e.g. 3-5 floating IPs. This ensures a more fair distribution of these resources for all cloud users. If a user wants to use more of these resources, the user **SHOULD** be able to pay for more. + +IP Usage Monitoring: SCS CSPs **SHOULD** implement monitoring solutions to track the utilization of IPv4 addresses. This facilitates efficient management of resources and supports capacity planning efforts. + +#### _External Network Naming_ -#### _Option 3_ -IP Usage Monitoring: SCS clouds must implement monitoring solutions to track the -utilization of IPv4 addresses. This facilitates efficient management of resources and -supports capacity planning efforts. +All SCS clouds **SHOULD** adopt the naming convention +scs-external-net for external networks. This standardization facilitates easier identification and management of external network resources. -#### _Option 4_ -External Network Naming: All SCS clouds must adopt the naming convention -scs-external-net for external networks. This standardization facilitates easier -identification and management of external network resources. +#### _Floating IPs_ -#### _Option 5_ -Floating IPs for Dynamic Allocation: Utilize Floating IPs to allow dynamic reassignment -of public IPv4 addresses to different instances (VMs or Loadbalancers), facilitating -high availability and fault tolerance. +Floating IPs for Dynamic Allocation: Utilization of Floating IPs to allow dynamic reassignment of public IPv4 addresses to different instances (VMs or Loadbalancers), facilitating high availability and fault tolerance. +Floating IPs **MUST** be enabled. ## Open questions - Naming Convention Flexibility: How rigid should the naming convention for external networks be across various SCS clouds? -- Security Policy Standardization: To what extent should security group policies be -standardized without impeding individual cloud providers' autonomy? +- Load Balancing: Do we want to dictate a Load Balancer or a set of Load Balancers or nothing at all? E.g. Octavia, Yawol ## Decision From 923c353bc702be9532da95098b2047043989cce9 Mon Sep 17 00:00:00 2001 From: cah-patrickthiem Date: Tue, 26 Mar 2024 18:50:54 +0100 Subject: [PATCH 3/3] fixup! Added more detailed standardization options regarding IPv4 networking and its components. --- Standards/scs-xxxx-v1-ipv4-networking-standard.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Standards/scs-xxxx-v1-ipv4-networking-standard.md b/Standards/scs-xxxx-v1-ipv4-networking-standard.md index 163cbe07a..7515c1c52 100644 --- a/Standards/scs-xxxx-v1-ipv4-networking-standard.md +++ b/Standards/scs-xxxx-v1-ipv4-networking-standard.md @@ -25,13 +25,13 @@ ease of use for IaaS users and DevOps teams. #### _Neutron Routers_ -Usage of Neutron Routers: To manage traffic between internal and external networks Neutron Routers **MUST** be used as the default gateway for VMs requiring access to external networks and the internet, thereby facilitating the routing of traffic and enhancing network security. +Usage of Neutron Routers: To manage traffic between internal and external networks Neutron Routers **MUST** be used as the default gateway for VMs requiring access to external networks and the internet, thereby facilitating the routing of traffic and enhancing network security. CSPs **SHOULD** use OVN or L3agent as High Availability (HA) service deployments. Standard external networks **MUST NOT** be made accessible as _shared networks_. It is advised that external networks are only reachable by the usage of routing and floating IPs. However, for special use cases like certain storage or VPN solutions it could be useful to allow _direct access networks_. -External networks and subnets **SHOULD** (very strong should) be configured with _--no-dhcp_ (DHCP - Dynamic Host Configuration Protocol). It is more secure to configure it like this, since it gives less space for reflection attacks, e.g. _Denial of Service_ (DOS) attacks. If _dhcp_ is configured, certain firewall configurations **MUST** be made to catch IPs from the _Neutron dhcp agent_ in the public network. +External networks and subnets **SHOULD** (very strong should) be configured with _--no-dhcp_ (DHCP - Dynamic Host Configuration Protocol). It is more secure to configure it like this, since it gives less space for reflection attacks, e.g. _Denial of Service_ (DOS) attacks. If _dhcp_ is configured, certain firewall configurations **MUST** be made to catch IPs from the _Neutron dhcp agent_ in the public network. #### _Neutron Plugins_