-
Bug
-
Resolution: Done
-
Undefined
-
None
-
OSSM 2.6.0, OSSM 3.0-TP1
-
None
Issue:
For application pods that have a sidecar and use an init container to interact with an external service via a FQDN (a probable common one being Vault) this has always been blocked by default (expected behaviour) and has required a workaround, see [1].
The workaround required the applications service account having the 'nonroot' scc and then defining 'runAsUser: 1337' like illustrated here [2] as by default all init containers are blocked to external services until the Istio sidecar is started. Configuring the uid to 1337 (the default for the sidecar proxy) allowed these external calls to work due to the pod iptables firewall rules configured by the CNI Plugin on initialisation which permit access to external services and DNS.
However, after conducting tests with an early build of OSSM 3.0 (istio 1.21) this workaround no longer functions. Consequently, deployments with init containers configured using this workaround will break. This change seems attributable to fixes incorporated into Istio [3] and [4], which appear to have been included in Istio 1.20 (so will affect 2.6 as well). The workaround logic/mechanism remains operational but now requires setting the uid to match the random proxy's uid (e.g. 1000739999).
Impact:
The impact of this change is that the initcontainer must now know which UID the istio sidecar will run under as there is no consistent uid option as like before. This is not predictable and depends on many factors and can change when the application deployments change.
References:
- blocks
-
OSSM-6598 Merge Istio 1.20.7 once it's released
- Release Pending