This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Istio
Use Istio when a cluster standard requires platform traffic to enter through an Istio ingress gateway. When you enable it, the Citrix SecurSpaces™ chart renders Istio Gateway, VirtualService, and DestinationRule resources instead of Kubernetes Ingress resources.
SecurSpaces does not install Istio. Install the Istio ingress gateway and confirm it is running before you deploy the chart.
Important:
The chart creates no SSH ingress when Istio is enabled. If your developers connect to workspaces over SSH, you build that path yourself. See SSH to workspaces.
Before you start
Make sure you have:
-
Istio 1.22 or later. The chart uses the stable
networking.istio.io/v1API. - An Istio ingress gateway already running in the cluster.
- Permission to create resources in the gateway namespace. The chart creates a Secret holding the internal services certificate authority there, along with the DestinationRules that select the gateway workload. Istio resolves both in the namespace of the gateway rather than the release namespace.
-
The labels that identify your gateway workload. Confirm them rather than assuming the default:
kubectl get pods -n <gateway-namespace> --show-labels <!--NeedCopy-->
Select Istio
Istio is chosen in the configuration file the installer generates, before you run Helm:
platform:
useIstio: true
istio:
gatewayNamespace: istio-system
gatewaySelector:
istio: ingressgateway
sslCertificateSecret: <your-tls-secret>
<!--NeedCopy-->
| Value | What it sets |
|---|---|
platform.useIstio |
Renders Istio resources instead of Ingress resources |
platform.istio.gatewayNamespace |
The namespace where the Istio ingress gateway workload runs |
platform.istio.gatewaySelector |
The labels that select the Istio ingress gateway workload |
The defaults shown above match a gateway installed with istioctl install. platform.ingressClass and the
controller-specific flags are ignored while useIstio is on.
Managed Istio distributions
Managed distributions label their gateway differently and run it in their own namespace. The Azure Kubernetes Service Istio add-on, for example, needs:
platform:
useIstio: true
istio:
gatewayNamespace: aks-istio-ingress
gatewaySelector:
istio: aks-istio-ingressgateway-external
<!--NeedCopy-->
What the chart creates
| Resource | What it does |
|---|---|
| Gateway for the platform host | Serves HTTP on port 80 with a redirect to HTTPS, and HTTPS on port 443 |
| Gateway for workspace subdomains | Serves the proxy hostname and its wildcard subdomain |
| VirtualService for the platform host | Routes each platform path to the service that serves it |
| VirtualService for workspace subdomains | Routes subdomains to the workspace API, and coordinator to the coordinator |
| DestinationRules, in the gateway namespace | Re-originate TLS to each service and verify the certificate |
| Services certificate authority Secret | Gives the gateway the authority it verifies those services against |
On the platform host, the chart routes gRPC-Web, SCIM, OAuth, SAML, and REST paths to the central service, workspace and browser paths to the workspace API, and everything else to the frontend.
Public TLS terminates at the Istio ingress gateway. The gateway then opens a second TLS connection to the SecurSpaces services, so traffic stays encrypted on the way through the cluster.
In an external region, the chart exposes only the workspace API, on that region’s own API host.
SecurSpaces stays outside the mesh
The SecurSpaces service pods opt out of Istio sidecar injection. The services already encrypt traffic between themselves with the internal services certificate authority, and keeping them out of the data path means cluster-wide mesh policy does not govern them.
This matters if your mesh applies either of the following, because both would otherwise break the platform:
- An
outboundTrafficPolicyofREGISTRY_ONLY, which would block outbound calls to Git providers, identity providers, and container registries. - A default-deny
AuthorizationPolicy, which would block the calls between SecurSpaces services.
The ingress gateway still routes to the services through the DestinationRules the chart creates.
SSH to workspaces
The Istio resources the chart creates carry HTTP and HTTPS only. Unlike NetScaler CPX™, which creates an SSH ingress and the service port for you, Istio leaves that path to you.
To offer SSH, expose TCP traffic to the workspace API service on port 2222 through your gateway, then enable SSH at the platform, organization, project, and workspace levels. The platform-side steps are the same whichever controller you use — see SSH TCP forwarding, and start at Enable SSH Access in the Platform.
Verify
After the release is deployed, confirm the resources exist and the gateway has an external address:
kubectl get gateway,virtualservice -n strong-network
kubectl get destinationrule -n <gateway-namespace>
kubectl get svc -n <gateway-namespace>
<!--NeedCopy-->
Expected result: two Gateways and two VirtualServices in the release namespace, a DestinationRule for each SecurSpaces service in the gateway namespace, and an external address on the gateway service.
If the platform host returns a 503, the gateway is matching the Gateway resource but cannot reach a service. Check that the DestinationRules landed in the gateway namespace and that their workload selector matches the gateway labels.
Related information
Share
Share
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.