Enable optional features on managed control plane
This page describes how to enable optional features on managed Cloud Service Mesh. For information on the in-cluster control plane, see Enabling optional features on the in-cluster control plane.
When you provision managed Cloud Service Mesh, supported features differ
based on the control plane implementation, and certain features are only
available via allowlist. See
supported features for details.
If you are using an IstioOperator
based configuration today, the
Migrate from IstioOperator tool can help
convert to the configuration supported by the managed control plane.
Distroless proxy image
If you directly onboarded to Cloud Service Mesh with a managed
TRAFFIC_DIRECTOR
control plane implementation, then only the distroless image type is supported. You cannot change it.If your fleet originally used the
ISTIOD
control plane implementation and was migrated to theTRAFFIC_DIRECTOR
implementation, your image type was left unchanged during migration, and you can change the image type to distroless yourself.
As a best practice, you should restrict the contents of a container runtime to only the necessary packages. This approach improves security and the signal-to-noise ratio of Common Vulnerabilities and Exposures (CVE) scanners. Istio provides proxy images based on distroless base images.
The distroless proxy image does not contain any binaries other than the proxy.
It is therefore not possible to exec
a shell or use curl
, ping
, or other
debug utilities inside the container. However, you can use ephemeral containers
to attach to a running workload Pod to be able to inspect it and run custom
commands. For example, see
Collecting Cloud Service Mesh logs.
The following configuration enables distroless images for the entire Cloud Service Mesh. An image type change requires each pod to restart and get re-injected to take effect.
apiVersion: v1
kind: ConfigMap
metadata:
name: istio-release-channel
namespace: istio-system
data:
mesh: |-
defaultConfig:
image:
imageType: distroless
You may override the imageType
by using the following pod annotation.
sidecar.istio.io/proxyImageType: debug
After changing the image type of a deployment using the annotation, the deployment should be restarted.
kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME
Because it does not require a debug base image, most types of proxy debugging
should use gcloud beta container fleet mesh debug proxy-status / proxy-config
(details).
Outbound Traffic Policy
By default outboundTrafficPolicy
is set to ALLOW_ANY
. In this mode, all
traffic to any external service is allowed. To control and restrict the traffic
to only the external services for which
service entries
are defined you can change the default behavior of ALLOW_ANY
to
REGISTRY_ONLY
.
The following configuration configures the
outboundTrafficPolicy
toREGISTRY_ONLY
:apiVersion: v1 kind: ConfigMap metadata: name: istio-release-channel namespace: istio-system data: mesh: |- outboundTrafficPolicy: mode: REGISTRY_ONLY
where release-channel is your release channel (
asm-managed
,asm-managed-stable
, orasm-managed-rapid
).You can make the previous necessary config changes in the configmap using the following command:
kubectl edit configmap istio-release-channel -n istio-system -o yaml
Run the following command to view the configmap:
kubectl get configmap istio-release-channel -n istio-system -o yaml
To verify that
outboundTrafficPolicy
is enabled withREGISTRY_ONLY
, ensure the following lines appear in themesh:
section.... apiVersion: v1 data: mesh: | outboundTrafficPolicy: mode: REGISTRY_ONLY ...
End user authentication
You can configure managed Cloud Service Mesh user authentication for browser-based end-user authentication and access control to your deployed workloads. For more information, see Configuring Cloud Service Mesh user authentication.
Configure the minimum TLS version for your workloads
If you directly onboarded to Cloud Service Mesh with a managed TRAFFIC_DIRECTOR
control plane implementation,
then you cannot change this setting.
You can use the minProtocolVersion
field to specify the minimum TLS version
for the TLS connections among your workloads. For more information on setting
the minimum TLS version and checking the TLS configuration of your workloads,
see Istio Workload Minimum TLS Version Configuration.
The following example shows a ConfigMap
setting the minimum TLS version for
workloads to 1.3:
apiVersion: v1
kind: ConfigMap
metadata:
name: istio-release-channel
namespace: istio-system
data:
mesh: |-
meshMTLS:
minProtocolVersion: TLSV1_3