Merge remote-tracking branch 'upstream-istio/master' into sync-upstream-master

Author: FilipB

.devcontainer/devcontainer.json

@@ -1,6 +1,6 @@
 {
   "name": "istio build-tools",
-  "image": "gcr.io/istio-testing/build-tools:master-6ac9cdb3d1ad09092398ab15574ce88cf2ac31ff",
+  "image": "gcr.io/istio-testing/build-tools:master-4d8a6668b6d46b3becc35f9b24467f841bbb020a",
   "privileged": true,
   "remoteEnv": {
     "USE_GKE_GCLOUD_AUTH_PLUGIN": "True",

README.md

@@ -17,7 +17,7 @@
 Istio is an open source service mesh that layers transparently onto existing distributed applications. Istio’s powerful features provide a uniform and more efficient way to secure, connect, and monitor services. Istio is the path to load balancing, service-to-service authentication, and monitoring – with few or no service code changes.
 
 - For in-depth information about how to use Istio, visit [istio.io](https://istio.io)
-- To ask questions and get assistance from our community, visit [Github Discussions](https://github.com/istio/istio/discussions)
+- To ask questions and get assistance from our community, visit [GitHub Discussions](https://github.com/istio/istio/discussions)
 - To learn how to participate in our overall community, visit [our community page](https://istio.io/about/community)
 
 In this README:
@@ -55,15 +55,10 @@ Istio is composed of these components:
   > simplifies and enhances how microservices in an application talk to each
   > other over the network provided by the underlying platform.
 
-- **Istiod** - The Istio control plane. It provides service discovery, configuration and certificate management. It consists of the following sub-components:
+* **Ztunnel** - A lightweight data plane proxy written in Rust,
+    used in Ambient mesh mode to provide secure connectivity and observability for workloads without sidecar proxies.
 
-    - **Pilot** - Responsible for configuring the proxies at runtime.
-
-    - **Citadel** - Responsible for certificate issuance and rotation.
-
-    - **Galley** - Responsible for validating, ingesting, aggregating, transforming and distributing config within Istio.
-
-- **Operator** - The component provides user friendly options to operate the Istio service mesh.
+- **Istiod** - The Istio control plane. It provides service discovery, configuration and certificate management.
 
 ## Repositories
 
@@ -88,8 +83,7 @@ contains platform-specific code to populate the
 when the application topology changes, as well as translate
 [routing rules](https://istio.io/latest/docs/reference/config/networking/) into proxy specific configuration.
 
-    - [security](security/). This directory contains [security](https://istio.io/latest/docs/concepts/security/) related code,
-including Citadel (acting as Certificate Authority), citadel agent, etc.
+    - [security](security/). This directory contains [security](https://istio.io/latest/docs/concepts/security/) related code.
 
 - [istio/proxy](https://github.com/istio/proxy). The Istio proxy contains
 extensions to the [Envoy proxy](https://github.com/envoyproxy/envoy) (in the form of

RELEASE_BRANCHES.md

@@ -55,7 +55,7 @@ for including it in the “.0” release. Otherwise, the PRs will not be merged
     * Behavioral changes should be highly scrutinized, while typo fixes don't require that level of scrutiny.
 * It is preferable that cherry-picks are done by the istio-testing bot.
     * Automated cherry-picks do not need subject-matter experts to approve if discussed in the original PR.
-    * To trigger the bot cherry pick, either;
+    * To trigger the bot cherry pick, either:
         * Apply the correct `cherrypick/release-X.XX` label to the PR, and the bot should pick it up.
         * Use an explicit PR comment command: `/cherry-pick release-X.XX`
         * It is strongly preferred to always apply the correct `cherrypick/` label manually to aid search and tracking, even if you use the comment command method.

VERSION

@@ -1 +1 @@
-1.28
+1.29

architecture/ambient/ztunnel.md

@@ -186,7 +186,7 @@ Additionally, `splice` will be used to make this proxying more efficient when po
 
 For traffic in the mesh, things are a bit more complex:
 
-1. If the destination has a waypoint proxy, we must send to it to the waypoint (using HBONE).
+1. If the destination has a waypoint proxy, we must send it to the waypoint (using HBONE).
    When we do this, we will want to preserve the original destination Service IP, as the waypoint can do a better job picking a backend pod than we can.
    Note: the application itself may have already resolved the Service IP to a specific pod if it has Kubernetes native routing built in; since we don't have the Service information in this case we will use the destination IP we received (a pod). Most notably, sidecar proxies behave this way.
 1. If the destination is on our node, we "fast path" the request and convert this into an inbound request.

architecture/networking/controllers.md

@@ -31,7 +31,7 @@ Aside from this, there are a few conveniences and workarounds built-in to the cl
 *All Istio Kubernetes usage should use this library and not operate on Kubernetes clients directly.*
 
 **`kclient.Client`** is a higher level wrapper around a Kubernetes resource, and is built up of sub-parts `kclient.Reader`, `kclient.Writer`, and `kclient.Informer`.
-Typically, the whole `kclient.Client` is used,though.
+Typically, the whole `kclient.Client` is used, though.
 
 Functionality offered by `kclient` includes:
 * Typed clients (via generics) and more ergonomic APIs
@@ -61,7 +61,7 @@ With a few exceptions, Istio controllers typically are split in two phases: cons
 
 Construction should create informers (via `kclient.New`), setup a queue (via `controllers.NewQueue`), and register event handlers on the informers.
 Often, these handlers are adding something to the queue like `client.AddEventHandler(controllers.ObjectHandler(queue.AddObject))`.
-Construction should NOT actually start running all of these things, do I/O, or block in anyway.
+Construction should NOT actually start running all of these things, do I/O, or block in any way.
 
 Running the controller actually starts processing things.
 Normally, this just means running the queue.

architecture/security/istio-agent.md

@@ -10,7 +10,7 @@ At a high level, the Istio agent acts as an intermediate proxy between Istiod an
 at two levels. For distributing workload certificates, Envoy will send [SDS](https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret)
 requests to the agent, causing the agent to submit a CSR to the configured CA (generally Istiod). For other configuration,
 Envoy will send [ADS](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/operations/dynamic_configuration#aggregated-xds-ads)
-requests to the agent, which will be forwarded to the configured discovery server (general Istiod).
+requests to the agent, which will be forwarded to the configured discovery server (generally Istiod).
 
 ## CA Flow
 

cni/README.md

@@ -4,11 +4,11 @@ The Istio CNI Node Agent is responsible for several things
 
 - Install an Istio CNI plugin binary on each node's filesystem, updating that node's CNI config in e.g (`/etc/cni/net.d`), and watching the config and binary paths to reinstall if things are modified.
 - In sidecar mode, the CNI plugin can configure sidecar networking for pods when they are scheduled by the container runtime, using iptables. The CNI handling the netns setup replaces the current Istio approach using a `NET_ADMIN` privileged `initContainers` container, `istio-init`, injected in the pods along with `istio-proxy` sidecars. This removes the need for a privileged, `NET_ADMIN` container in the Istio users' application pods.
-- In ambient mode, the CNI plugin does not configure any networking, but is only responsible for synchronously pushing new pod events back up to an ambient watch server which runs as part of the Istio CNI node agent. The ambient server will find the pod netns and configure networking inside that pod via iptables. The ambient server will additionally watch enabled namespaces, and enroll already-started-but-newly-enrolled pods in a similar fashion.
+- In ambient mode, the CNI plugin does not configure any networking but is only responsible for synchronously pushing new pod events back up to an ambient watch server which runs as part of the Istio CNI node agent. The ambient server will find the pod netns and configure networking inside that pod via iptables. The ambient server will additionally watch enabled namespaces and enroll already-started-but-newly-enrolled pods in a similar fashion.
 
 ## Development
 
-The Istio cni-plugin has a hard dependency on Linux. Some efforts have been made to allow non-funtional builds on non-Linux OSes but these are not universal. For most any reasonable intents and purposes only building on Linux is supported. If you are on a non-Linux development environment use `make shell`.
+The Istio cni-plugin has a hard dependency on Linux. Some efforts have been made to allow non-functional builds on non-Linux OSes but these are not universal. For most any reasonable intents and purposes only building on Linux is supported. If you are on a non-Linux development environment use `make shell`.
 
 Most any Linux architecture supported by Go should work. Istio is only tested on AMD64 and ARM64.
 
@@ -35,7 +35,7 @@ Broadly, `istio-cni` accomplishes ambient redirection by instructing ztunnel to
 
 and setting up iptables rules to funnel traffic thru that socket "tube" to ztunnel and back.
 
-This effectively behaves like ztunnel is an in-pod sidecar, without actually requiring the injection of ztunnel as a sidecar into the pod manifest, or mutatating the application pod in any way.
+This effectively behaves like ztunnel is an in-pod sidecar, without actually requiring the injection of ztunnel as a sidecar into the pod manifest, or mutating the application pod in any way.
 
 Additionally, it does not require any network rules/routing/config in the host network namespace, which greatly increases ambient mode compatibility with 3rd-party CNIs. In virtually all cases, this "in-pod" ambient CNI is exactly as compatible with 3rd-party CNIs as sidecars are/were.
 
@@ -71,8 +71,8 @@ The annotation based control is currently only supported in 'sidecar' mode. See
 
 - redirectMode allows TPROXY may to be set, required envoy has extra permissions. Default is redirect.
 - includeIPCidr, excludeIPCidr
-- includeInboudPorts, excludeInboundPorts
-- includeOutboutPorts, excludeOutboundPorts
+- includeInboundPorts, excludeInboundPorts
+- includeOutboundPorts, excludeOutboundPorts
 - excludeInterfaces
 - kubevirtInterfaces (deprecated), reroute-virtual-interfaces
 - ISTIO_META_DNS_CAPTURE env variable on the proxy - enables dns redirect

cni/pkg/cmd/root.go

@@ -112,6 +112,11 @@ var rootCmd = &cobra.Command{
 			if err != nil {
 				return fmt.Errorf("failed to instantiate ambient enablement selector: %v", err)
 			}
+
+			if cfg.InstallConfig.NativeNftables && cfg.InstallConfig.ForceIptablesBinary != "" {
+				log.Warn("NativeNftables is enabled along with ForceIptablesBinary. Using native nftables and ignoring iptables")
+			}
+
 			ambientAgent, err := nodeagent.NewServer(ctx, watchServerReady, cniEventAddr,
 				nodeagent.AmbientArgs{
 					SystemNamespace:            nodeagent.SystemNamespace,
@@ -122,6 +127,7 @@ var rootCmd = &cobra.Command{
 					EnableIPv6:                 cfg.InstallConfig.AmbientIPv6,
 					ReconcilePodRulesOnStartup: cfg.InstallConfig.AmbientReconcilePodRulesOnStartup,
 					NativeNftables:             cfg.InstallConfig.NativeNftables,
+					ForceIptablesBinary:        cfg.InstallConfig.ForceIptablesBinary,
 				})
 			if err != nil {
 				return fmt.Errorf("failed to create ambient nodeagent service: %v", err)
@@ -324,7 +330,8 @@ func constructConfig() (*config.Config, error) {
 		AmbientDisableSafeUpgrade:         viper.GetBool(constants.AmbientDisableSafeUpgrade),
 		AmbientReconcilePodRulesOnStartup: viper.GetBool(constants.AmbientReconcilePodRulesOnStartup),
 
-		NativeNftables: viper.GetBool(constants.NativeNftables),
+		NativeNftables:      viper.GetBool(constants.NativeNftables),
+		ForceIptablesBinary: os.Getenv("FORCE_IPTABLES_BINARY"),
 	}
 
 	if len(installCfg.K8sNodeName) == 0 {
@@ -342,20 +349,21 @@ func constructConfig() (*config.Config, error) {
 	}
 
 	repairCfg := config.RepairConfig{
-		Enabled:            viper.GetBool(constants.RepairEnabled),
-		RepairPods:         viper.GetBool(constants.RepairRepairPods),
-		DeletePods:         viper.GetBool(constants.RepairDeletePods),
-		LabelPods:          viper.GetBool(constants.RepairLabelPods),
-		LabelKey:           viper.GetString(constants.RepairLabelKey),
-		LabelValue:         viper.GetString(constants.RepairLabelValue),
-		NodeName:           viper.GetString(constants.RepairNodeName),
-		SidecarAnnotation:  viper.GetString(constants.RepairSidecarAnnotation),
-		InitContainerName:  viper.GetString(constants.RepairInitContainerName),
-		InitTerminationMsg: viper.GetString(constants.RepairInitTerminationMsg),
-		InitExitCode:       viper.GetInt(constants.RepairInitExitCode),
-		LabelSelectors:     viper.GetString(constants.RepairLabelSelectors),
-		FieldSelectors:     viper.GetString(constants.RepairFieldSelectors),
-		NativeNftables:     viper.GetBool(constants.NativeNftables),
+		Enabled:             viper.GetBool(constants.RepairEnabled),
+		RepairPods:          viper.GetBool(constants.RepairRepairPods),
+		DeletePods:          viper.GetBool(constants.RepairDeletePods),
+		LabelPods:           viper.GetBool(constants.RepairLabelPods),
+		LabelKey:            viper.GetString(constants.RepairLabelKey),
+		LabelValue:          viper.GetString(constants.RepairLabelValue),
+		NodeName:            viper.GetString(constants.RepairNodeName),
+		SidecarAnnotation:   viper.GetString(constants.RepairSidecarAnnotation),
+		InitContainerName:   viper.GetString(constants.RepairInitContainerName),
+		InitTerminationMsg:  viper.GetString(constants.RepairInitTerminationMsg),
+		InitExitCode:        viper.GetInt(constants.RepairInitExitCode),
+		LabelSelectors:      viper.GetString(constants.RepairLabelSelectors),
+		FieldSelectors:      viper.GetString(constants.RepairFieldSelectors),
+		NativeNftables:      viper.GetBool(constants.NativeNftables),
+		ForceIptablesBinary: os.Getenv("FORCE_IPTABLES_BINARY"),
 	}
 
 	return &config.Config{InstallConfig: installCfg, RepairConfig: repairCfg}, nil

cni/pkg/config/config.go

@@ -158,6 +158,9 @@ type InstallConfig struct {
 
 	// Whether native nftables should be used instead of iptable rules for traffic redirection
 	NativeNftables bool
+
+	// Choose which iptables binary to use (legacy or nft)
+	ForceIptablesBinary string
 }
 
 // RepairConfig struct defines the Istio CNI race repair configuration
@@ -175,7 +178,7 @@ type RepairConfig struct {
 	// Whether to fix race condition by repairing them
 	RepairPods bool
 
-	// Whether to fix race condition by delete broken pods
+	// Whether to fix race condition by deleting broken pods
 	DeletePods bool
 
 	// Whether to label broken pods
@@ -194,6 +197,9 @@ type RepairConfig struct {
 
 	// Whether to repair pods by running nftables rules
 	NativeNftables bool
+
+	// Choose which iptables binary to use (legacy or nft)
+	ForceIptablesBinary string
 }
 
 func (c InstallConfig) String() string {
@@ -231,6 +237,7 @@ func (c InstallConfig) String() string {
 	b.WriteString("AmbientReconcilePodRulesOnStartup: " + fmt.Sprint(c.AmbientReconcilePodRulesOnStartup) + "\n")
 
 	b.WriteString("NativeNftables: " + fmt.Sprint(c.NativeNftables) + "\n")
+	b.WriteString("ForceIptablesBinary: " + fmt.Sprint(c.ForceIptablesBinary) + "\n")
 	return b.String()
 }
 
@@ -249,5 +256,6 @@ func (c RepairConfig) String() string {
 	b.WriteString("LabelSelectors: " + c.LabelSelectors + "\n")
 	b.WriteString("FieldSelectors: " + c.FieldSelectors + "\n")
 	b.WriteString("NativeNftables: " + fmt.Sprint(c.NativeNftables) + "\n")
+	b.WriteString("ForceIptablesBinary: " + fmt.Sprint(c.ForceIptablesBinary) + "\n")
 	return b.String()
 }