You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/about/index.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,9 @@ comments: false
9
9
10
10
Welcome to my blog. I am a Platform Security Engineer by profession. I also have an extensive background in Network Engineering and Infrastructure automation. Generally speaking, I enjoy learning and working at the intersection of networking, systems, software & security. During my downtime I enjoy amateur boxing, working on my homelab, traveling, hiking or kayaking.
11
11
12
-
I am really passionate about learning and sharing. Since I rely heavily on open source and the work that others put out online for free, I wanted to share some of the cool stuff that I get to learn and work on which I usually end up documenting somewhere in my notes anyway. My hope is that someone on the internet could benefit from the information here and it also gives me a good reason to finally start using this domain that I have been squatting on for so long.
12
+
I am really passionate about learning and sharing. Since I rely heavily on open source and the work that others put out online for free, I wanted to share some of the cool stuff that I get to learn and work on which I usually end up documenting somewhere in my notes anyway. My hope is that someone on the internet could benefit from the information here, and it also gives me a good reason to finally start using this domain that I have been squatting for so long 😄
13
+
14
+
> Any ideas, opinions, and views expressed on this website are entirely my own and do not reflect those of my employer
Copy file name to clipboardExpand all lines: content/series/k8s-cilium-ipv6/part3.md
+10-8Lines changed: 10 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,16 +28,20 @@ Although Cilium’s documentation clearly outlines the [pros and cons](https://d
28
28
29
29
Designing for IPv6 in Kubernetes isn’t just about addressing — it’s about preserving visibility, scalability, and security in a modern, cloud-native network. The following principles shape our approach:
30
30
31
-
*Route wherever possible, masquerade only when necessary*<br>
31
+
> Route wherever possible, masquerade only when necessary
32
+
32
33
Network transparency is a key advantage of IPv6. By minimizing NAT, we retain end-to-end visibility and simplify troubleshooting across the cluster.
33
34
34
-
*Maintain clean ingress and egress paths*<br>
35
+
> Maintain clean ingress and egress paths
36
+
35
37
Avoiding unnecessary address translation ensures that north–south traffic remains predictable and auditable which is a crucial factor when integrating with enterprise firewalls and IDS solutions.
36
38
37
-
*Align with existing enterprise security models*<br>
39
+
> Align with existing enterprise security models
40
+
38
41
Security teams rely on perimeter-based inspection tools like Zeek or Suricata following defense in depth approach. The way we design the cluster network must ensure these tools can continue to monitor north–south flows effectively, allowing security analysts to correlate events and logs with familiar tools.
39
42
40
-
*Adopt true micro segmentation*<br>
43
+
> Adopt true micro segmentation
44
+
41
45
Each application be placed in its own /64 IPv6 subnet, following RFC 7421 and RFC 8504. This enables fine-grained policy enforcement and isolates workloads at the network layer. Further fine-grained policies may be applied via Kubernetes network policies if necessary.
42
46
43
47
Implementing an IPv6 only Kubernetes cluster with these design principles is possible using Cilium with the following approach
@@ -65,8 +69,8 @@ An IPv6 only cluster sounds great, until you realize no one outside the cluster
| Ingress CIDR | IP address for making an application accessible from outside the cluster. In Kubernetes lingo, ingress is deprecated and is replaced by `GatewayAPI`. But conceptually they both solve the same problem. | Yes | When traffic originating from outside needs to connect to an application that is running within the cluster, the application must expose itself behind a Gateway API object. This is analogous to using a Virtual IP (VIP) on a Load Balancer. <br>`[end-user]-->[ingress vip]-->[app]`<br>`[end-user]<--[ingress vip]<--[app]`<br> For an external user to access the application via ingress address, the ingress VIP must be routed. These VIPs can be announced over BGP to the upstream router. Applicaiton's DNS record points to this Ingress VIP. |
69
-
| Egress CIDR (Optional, Reserved) | Used for outbound traffic to provide a stable/unique address (via masquerading) to each application. Since we are not using an egress gateway, we don't need to worry about this one, but it is generally a good idea to reserve some address space if we ever need to make changes to our design in the future | Yes | This is particularly useful when using ULA/RFC1918 addresses for Pod CIDR. When pod traffic needs to reach a destination IP which is located outside the cluster those packets will need to egress out of somewhere. One common pattern is to use an egress gateway. In presence of egress gateway *egress traffic is masqueraded* with a stable IP address for the packet to reach the final destination.|
72
+
| Ingress CIDR | IP address for making an application accessible from outside the cluster. In Kubernetes lingo, ingress is deprecated and is replaced by `GatewayAPI`. But conceptually they both solve the same problem. | Yes | When traffic originating from outside needs to connect to an application that is running within the cluster, the application must expose itself behind a Gateway API object. This is analogous to using a Virtual IP (VIP) on a Load Balancer. <br>`[end-user]-->[ingress vip]-->[app]`<br>`[end-user]<--[ingress vip]<--[app]`<br> For an external user to access the application via ingress address, the ingress VIP must be routed. These VIPs can be announced over BGP to the upstream router. Application's DNS A/AAAA record points to this Ingress VIP. |
73
+
| Egress CIDR (Optional) | Used for outbound traffic to provide a stable/unique address (via masquerading) to each application. Since we are not using an egress gateway, we don't need to worry about this one, but it is generally a good idea to reserve some address space if we ever need to make changes to our design in the future | Yes | This is particularly useful when using ULA/RFC1918 addresses for Pod CIDR. When pod traffic needs to reach a destination IP which is located outside the cluster those packets will need to egress out of somewhere. One common pattern is to use an egress gateway. In presence of egress gateway *egress traffic is masqueraded* with a stable IP address for the packet to reach the final destination.|
70
74
71
75
So if we try to allocate these subnets in our original address block `2001:db8::/48` which we used in part 1 here's what that address plan layout looks like
72
76
@@ -125,8 +129,6 @@ Cilium has a robust BGP control plane implementation which fits really well for
125
129
126
130
For IPv6-only networks where PodCIDR is routed using Cilium's native-routing, pods can obtain a global unicast address (GUA) by using [multi-pool](https://docs.cilium.io/en/stable/network/concepts/ipam/multi-pool/) IPAM. While other IPAM modes in Cilium (such as cluster scope, Kubernetes host scope) can also be configured to hand out GUA addresses, they are [not as flexible](https://docs.cilium.io/en/stable/network/concepts/ipam/#address-management) as multi-pool IPAM. While Cilium's documentation (as of 1.18.x) indicates this IPAM mode is still considered "Beta", 1.18.0 release has flushed out most of the bugs and limitations that existed for it to work as an IPAM mode for IPv6 clusters. Using GUA addresses for pods eliminates the need for a dedicated egress gateway and keeps the egress traffic path clean which in lines with our design philosophy mentioned above.
127
131
128
-
> Cilium’s multi-pool IPAM combined with native routing feels like the holy grail of Kubernetes networking for IPv6-only clusters!
129
-
130
132
## How Cilium's IPAM works
131
133
132
134
While the internal details of Cilium’s IPAM implementation are beyond the scope of this series (that could be a separate series in itself 😄), here’s a *general high-level overview* of how the multi-pool IPAM works:
0 commit comments