libesz

# This is an improved version of egress routing config for istio.
# I published the original here: https://istio.io/latest/blog/2023/egress-sni/
# This config is a drop-in replacement for the the blog's second code block.

# Since ser filter state is GA in envoy, we can use it on the sidecar side to
# properly set up the original requested server name from the application in the
# mesh mTLS SNI.

# Define a new listener that enforces Istio mTLS on inbound connections.
# This is where sidecar will route the application traffic, wrapped into

libesz

# Use-case: have a set of (possibly wildcard) external target hostnames 
# that are approached with TLS (HTTPS) by mesh applications. Traffic towards
# these targets are routed through an egress gateway with the mesh mTLS.
# Egress gateway checks the hostname and if allowed, dynamically forwards the
# traffic to the exact destination that is in the SNI property.
#
# This version uses an internal listener to dispatch the final destination
# from the application traffic.
# Istio release independent.

libesz

# Use-case: have a set of (possibly wildcard) external target hostnames 
# that are approached with TLS (HTTPS) by mesh applications. Traffic towards
# these targets are routed through an egress gateway with the mesh mTLS.
# Egress gateway checks the hostname and if allowed, dynamically forwards the
# traffic to the exact destination that is in the SNI property.

apiVersion: v1
kind: Service
metadata:
  name: egressgateway

libesz

# Use-case: have a set of (possibly wildcard) external target hostnames 
# that are approached with TLS (HTTPS) by mesh applications. Traffic towards
# these targets are routed through an egress gateway with the mesh mTLS.
# Egress gateway checks the hostname and if allowed, dynamically forwards the
# traffic to the exact destination that is in the SNI property.
#
# The very last patch requires Istio 1.20+. Before 1.20, the istio fork based 
# forward_downstream_sni EnvoyFilter implementation can be used.

apiVersion: v1

libesz

Note: this description is deprecated if you use the latest DANM binary with this PR merged: nokia/danm#34

Kubernetes setup with Danm

This is a rough step list how I managed to upgrade a simple Flannel based Kubernetes cluster to use Danm, while all common (platform?) services are still working (such as Helm, CoreDNS, Prometheus). The goal is to still use Flannel for the platform services. Flannel allows them to access K8S API or native services running on the host. An alternative could be to use host network namespace for the platform services, but it is not that fun 😊. Since Danmnet CRD objects are namespaced, we have to delegate the CNI setup to Flannel in all K8S namespaces where needed, like kube-system.

• Started with kubeadm installed 3 nodes cluster
  • Centos 7.4 with 4.19 kernel
  • Single master, schedulable
• Kubernetes version 11.1.2

libesz

/* Dummy one-filer go program to demonstrate the basic pattern
   of a simple worker pool with a context, a waitgroup and a channel.

   I crafted this when I wanted to (again) understand the go concurrency
   patterns. Than now, I found it clean enough and added verbose comments
   so that anyone can understand or complain :).

   So, the following language properties can be inspected:
   - Channels may have multiple senders and/or receivers
	 - Here we have multiple receivers (workers in a pool) and a single sender

libesz

/*
 * Sample C code to obtain the IP address attached to
 * a selected network interface under Linux.
 *
 * Found here: http://www.geekpage.jp/en/programming/linux-network/get-ipaddr.php
 *
 * Missing includes added.
 */

#include <stdio.h>