feat(vpc): nacls

Author: RoRoJ

menu/navigation.json

@@ -2988,6 +2988,10 @@
                     "label": "Manage routing on a VPC",
                     "slug": "manage-routing"
                   },
+                  {
+                    "label": "Manage Network ACLs",
+                    "slug": "manage-nacl"
+                  },
                   {
                     "label": "Delete a Private Network",
                     "slug": "delete-private-network"
@@ -3012,17 +3016,21 @@
               },
               {
                 "items": [
+                  {
+                    "label": "Getting the most from Private Networks",
+                    "slug": "getting-most-private-networks"
+                  },
                   {
                     "label": "Understanding routing",
                     "slug": "understanding-routing"
                   },
                   {
-                    "label": "Understanding DNS",
-                    "slug": "dns"
+                    "label": "Understanding NACLs",
+                    "slug": "understanding-nacls"
                   },
                   {
-                    "label": "Getting the most from Private Networks",
-                    "slug": "getting-most-private-networks"
+                    "label": "Understanding DNS",
+                    "slug": "dns"
                   },
                   {
                     "label": "VPC use case 1: basic infrastructure",

pages/vpc/concepts.mdx

@@ -64,7 +64,7 @@ When an IPv6-compatible resource is attached to a Private Network, it has a priv
 
 ## Network ACL
 
-A VPC's Network **A**ccess **C**ontrol **L**ist is composed of stateless rules to control the flow of traffic between Private Networks. By default, the list contains no rules and therefore traffic is allowed to flow unrestrictedly between the VPC's Private Networks. [Add rules](/vpc/how-to/manage-nacl/) to the list to start creating restrictions.
+A VPC's Network **A**ccess **C**ontrol **L**ist is composed of stateless rules to control the flow of traffic between Private Networks. By default, the list contains no rules and therefore traffic is allowed to flow unrestrictedly between the VPC's Private Networks. [Add rules](/vpc/how-to/manage-nacl/) to the list to start creating restrictions. [Take a deeper diver into NACLs](/vpc/reference-content/understanding-nacls/).
 
 ## Private IP address
 

pages/vpc/reference-content/assets/scaleway-nacl-diag-detail.webp

@@ -35,17 +35,19 @@ One default VPC for each region is automatically created in each Scaleway [Proje
 
 <Lightbox src="scaleway-routing-diag.webp" alt="A diagram shows two Private Networks inside a VPC. A route table on a virtual router sits inside the VPC, and the route table is synchronized to each resource attached to the VPC's Private Networks. An Instance on Private Network A is able to send a packet to an Instance on Private Network B. An Elastic Metal server on Private Network A is able to send a packet to the public internet via the Public Gateway also on Private Network A." />
 
+You can nonetheless add rules to a VPC's inbuilt [Network Access Control List](/vpc/reference-content/understanding-nacls/) (NACL) to filter and restrict the flow of traffic between the different Private Networks of a VPC.
+
 ## Designing your network topology
 
-When you start creating resources and building your infrastructure with Scaleway, take some time to consider and plan your network topology. We recommend that you build your VPC infrastructure with **separation of concerns** in mind. Separation of concerns is a fundamental design principle aimed at breaking down large complex systems into smaller, distinct components each with clear responsibilities and interfaces. This kind of design will future-proof your VPC and come into its own when Scaleway introduces further features such as ACLs for VPC.
+When you start creating resources and building your infrastructure with Scaleway, take some time to consider and plan your network topology. We recommend that you build your VPC infrastructure with **separation of concerns** in mind. Separation of concerns is a fundamental design principle aimed at breaking down large complex systems into smaller, distinct components each with clear responsibilities and interfaces. This kind of design will future-proof your VPC.
 
  Separating resources into different Private Networks according to function and usage can:
 - **Improve network performance** by reducing broadcast traffic and congestion
 - **Enhance manageability** via a logical organization of resources
 - **Enable easier troubleshooting, monitoring and maintenance**
 - **Allow for easier scalability**
 
-For example, you may use one Private Network for frontend resources and another for backend resources, limiting public access only via Load Balancers and/or Public Gateways, stripping other resources of public IP addresses. You may want to create different VPCs for production and test environments, allowing you to isolate potential errors in testing from the production environment.
+For example, you may use one Private Network for frontend resources and another for backend resources, limiting public access only via Load Balancers and/or Public Gateways, stripping other resources of public IP addresses. You may want to create different VPCs for production and test environments, allowing you to isolate potential errors in testing from the production environment. You can also use NACLs to restrict traffic flow between certain IP ranges and ports within the Private Networks of a VPC.
 
 When [creating a Private Network](/vpc/how-to/create-private-network/), you can let Scaleway automatically generate a CIDR block for it that is guaranteed to be unique in this VPC. All resources attached to the Private Network get a private IP address from this block. However, you also have the option to define your own CIDR block for the network. Ensure you choose a prefix and network size that is appropriate for your needs, does not overlap with that of any other Private Network in the VPC, and contains enough IP addresses for all resources that will be attached to the Private Network.
 

pages/vpc/reference-content/assets/scaleway-nacls-table.webp

@@ -13,22 +13,24 @@ categories:
   - network
 ---
 
-Every VPC has a Network **A**ccess **C**ontrol **L**ist (NACL). This list is composed of stateless rules to control the flow of traffic between the Private Networks fo the VPC. By default, at first the list contains no rules and therefore traffic is allowed to flow unrestrictedly.
+Every VPC has a Network **A**ccess **C**ontrol **L**ist (NACL). This list is composed of stateless rules to control the flow of traffic between the Private Networks fo the VPC. By default, at first the list contains no rules and therefore traffic is allowed to flow unrestrictedly. You can add rules to restrict traffic flow  according to your requirements.
 
 This document sets out general information and best practices about Scaleway VPC NACLs.
 
 - For instructions on managing NACLs via the Scaleway console, see [How to manage Network ACLs](/vpc/how-to/manage-nacl/)
-- To manage NACLs via the Scaleway API, see the [VPC API doumentation](https://www.scaleway.com/en/developers/api/vpc/)
+- To manage NACLs via the Scaleway API, see the [VPC API documentation](https://www.scaleway.com/en/developers/api/vpc/)
 - For other interfaces, see the documentation of the [relevant developer tool](https://www.scaleway.com/en/developers/)
 
 ## Network ACL overview
 
-Every Scaleway VPC has a Network ACL. In its initial state, it contains no rules and allows all traffic to flow freely between the Private Networks of the VPC.
+Every Scaleway VPC has a Network ACL. In its initial state, it contains no rules. Thanks to [managed routing](/vpc/reference-content/understanding-routing/), which automatically routes traffic between Private Networks, traffic is freely routed between the Private Networks of the VPC.
 
 When you start adding rules to your NACL, traffic flow is restricted between certain sources and destinations within the VPC, according to the rules you set. A default rule is added to the NACL, which dictates the action to take on traffic that does not match of the rules in the list: it can either be **allowed** or **denied**.
 
 <Lightbox src="scaleway-nacl-diag-simple.webp" alt="A schema shows how the NACL sits at the intersection of two Private Networks in a Scaleway VPC" />
 
+<Lightbox src="scaleway-nacls-table.webp" alt="A table shows three NACL rules, one to block access to PostgreSQL from a dev PN, the second to block all traffic from PN A to PN B, and the third being a default rule that allows all other traffic" />
+
 NACL rules are stateless, meaning that the state of connections is not tracked, and return traffic is not automatically allowed, just because the outbound request was allowed. Explicit rules are required for each direction of traffic.
 
 NACLs only control traffic as it enters or exits the Private Network(s) of a VPC. They do not:
@@ -51,7 +53,7 @@ When defining an NACL rule, you must enter the following settings:
 
 - **Source** and **destination**: The rule will apply to traffic originating from this source and being sent to this destination. For both, enter an IP range range in [CIDR format](/vpc/concepts/#cidr-block), and a port or port range. Alternatively, you can opt for the rule to apply to**All IPs** and/or **All ports**.
 
-- **Action**: The NACL will either **Allow** or *Deny** traffic that matches the rule, to to proceed to its destination.
+- **Action**: The NACL will either **Allow** or **Deny** traffic that matches the rule, to proceed to its destination.
 
 ## Rule priority and application
 
@@ -63,7 +65,7 @@ The Network Access Control List should be read from top to bottom. Rules closer
 
 Therefore, if you create a rule to allow traffic in one direction, you may also need a separate rule to allow the response in the opposite direction. There is a functionality to auto-generate matching inverse rules for this purpose when creating a new rule.
 
-TODO: example of how traffic that is allowed to one destination won't be llowed to return without correct rule
+TODO: example of how traffic that is allowed to one destination won't be allowed to return without correct rule
 
 ## Default rule
 
@@ -75,4 +77,5 @@ TODO: examples of how default rule works as either allow or deny (see https://do
 TODO:
 - Ephemeral ports?
 - Examples
-- Best practices (see https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html)
+- Quotas
+- What you can/can't block with NACLs

pages/vpc/reference-content/getting-most-private-networks.mdx

@@ -23,7 +23,9 @@ Managed routes are also automatically added to the VPC’s routing table when yo
 
 You can create your own custom routes to send traffic for defined IP ranges towards a specified resource in the VPC, for example if you want to route to a VPN installed on an Instance.
 
-Routing is activated by default whenever you create a new VPC, and can be activated on pre-existing VPCs by [following these steps](/vpc/how-to/manage-routing/#how-to-activate-routing). More routing features are planned for the future, such as ACLs and firewalling.
+Routing is activated by default whenever you create a new VPC, and can be activated on pre-existing VPCs by [following these steps](/vpc/how-to/manage-routing/#how-to-activate-routing).
+
+You can add rules to your VPC's [Network ACL](/vpc/reference-content/understanding-nacls/) to filter and restrict traffic flow between attached resources and Private Networks.
 
 The diagram below shows an example of how routing works across two Private Networks on a VPC. The route table is held on the VPC's virtual router ([VRouter](/vpc/concepts/#vrouter)), and synched to each resource as it joins a Private Network. 
 - An Elastic Metal server on Private Network A can send a packet to the public internet via a Public Gateway also attached to Private Network A.
@@ -61,20 +63,22 @@ Bear in mind the following when activating VPC routing:
 
 - Once activated on a given VPC, routing cannot be deactivated on that VPC.
 - When routing is activated, all Private Networks on the VPC can communicate.
-- We do not currently offer an ACL/firewall feature to prevent communication between certain Private Networks/resources once routing is activated. However, users may choose to configure ACLs directly on certain resources (e.g. Instances, Elastic Metal servers) using tools such as `iptables` or `nftables`.
+- You can use [NACL rules](/vpc/reference-content/understanding-nacls/) to restrict traffic flow between certain sources and destinations within the VPC.
 - Public Gateways remain scoped to the Private Network to which they are attached. They do not advertise the default route on other Private Networks in the VPC. For example, an Instance attached to Private Network A will not be able to access the internet via a Public Gateway in Private Network B.
 
 ## Best practices
 
-We recommend that you build your VPC infrastructure with **separation of concerns** in mind. Separation of concerns is a fundamental design principle aimed at breaking down large complex systems into smaller, distinct components each with clear responsibilities and interfaces. This kind of design will future-proof your VPC and come into its own when we introduce features such as custom routing and ACLs.
+We recommend that you build your VPC infrastructure with **separation of concerns** in mind. Separation of concerns is a fundamental design principle aimed at breaking down large complex systems into smaller, distinct components each with clear responsibilities and interfaces. This kind of design will future-proof your VPC.
 
  Separating resources into different Private Networks according to function and usage can:
 - Improve network performance by reducing broadcast traffic and congestion
 - Enhance manageability via a logical organization of resources
 - Enable easier troubleshooting, monitoring and maintenance
 - Allow for easier scalability
+- Isolate sensitive resources
+- Enable the provision of an additional layer of security via a Network ACL, to further protect sensitive resources
 
-For example, you may use one Private Network for frontend resources and another for backend resources, limiting public access only via Load Balancers and/or Public Gateways.
+For example, you may use one Private Network for frontend resources and another for backend resources, limiting public access only via Load Balancers and/or Public Gateways, and adding NACL rules to prevent traffic flow from certain frontend resources to certain backend resources. 
 
 ## Limitations