Authentication to External Istiod

[haithamshahin333]

Hello,

I was hoping someone can clarify how a gateway in a remote cluster initially authenticates to an external Istiod instance? Specifically in the following primary-remote deployment example how does the ingress gateway in cluster 2 initially authenticate to istiod in cluster 1? Does it use mutual TLS? Or Kubernetes Service Token? Or both?

[abasitt]

Its the same as if istiod is within a cluster, the boostrap process remains the same.
If you check the istio-system namespace of the remote cluster, you will find a service-name of istiod pointing to the primary istiod.

• gateway pods or sidecars in remote cluster authenticate initially with service account. https://istio.io/latest/docs/ops/best-practices/security/#configure-third-party-service-account-tokens

• the communication with istiod is over mtls. you should be able to see something like below in the bootstrap config.
  "controlPlaneAuthPolicy": "MUTUAL_TLS",

[rootsongjc]

@haithamshahin333 In the Install Primary-Remote on different networks documentation, there is a step titled Attach cluster2 as a remote cluster of cluster1. In this step, a secret is generated that looks like the following:

# This file is autogenerated, do not edit.
apiVersion: v1
kind: Secret
metadata:
  annotations:
    networking.istio.io/cluster: cluster2
  creationTimestamp: null
  labels:
    istio/multiCluster: "true"
  name: istio-remote-secret-cluster2
  namespace: istio-system
stringData:
  cluster2: |
    apiVersion: v1
    clusters:
    - cluster:
        certificate-authority-data: {CERTIFICATE}
        server: {CLUSTER2-APISERVER-ADDRESS}
      name: cluster2
    contexts:
    - context:
        cluster: cluster2
        user: cluster2
      name: cluster2
    current-context: cluster2
    kind: Config
    preferences: {}
    users:
    - name: cluster2
      user:
        token: {TOKEN}

The data inside this secret is actually a kubeconfig configuration file, which includes certificates and tokens needed to access cluster2. In the primary cluster, Istio uses this kubeconfig to access the API server of cluster2, thereby obtaining information about services in cluster2.

Additionally, cluster2 contains an Istiod service, and its endpoints are the load balancer IP:15012 and IP:15017 of the Istiod service in the primary cluster. This allows cluster2 to access Istiod in the primary cluster via Istiod.

Because the remote cluster and the primary cluster share the same CA (the CA of the primary cluster), and the remote cluster can also access its own API server, Istiod in the primary cluster can authenticate requests coming from cluster2. The following diagram illustrates the process of establishing mTLS connections between the Ingress Gateway in the remote cluster and Istiod in the primary cluster:

sequenceDiagram
    participant IG as Ingress Gateway (Remote Cluster)
    participant K8s as Kubernetes API (Remote Cluster)
    participant SA as Service Account (Remote Cluster)
    participant Istiod as Istiod (Primary Cluster)

    Note over IG: Starts up
    IG->>K8s: Request Service Account Token
    K8s->>SA: Create/Retrieve Token
    SA-->>IG: Return Token
    Note over IG: Token Mounted in Pod

    IG->>Istiod: Authenticate with Token
    Note over Istiod: Validate Token
    Istiod->>Istiod: Generate mTLS Certificates
    Istiod-->>IG: Send mTLS Certificates

    Note over IG: Use mTLS Certificates for Secure Communication in Mesh

See more on this blog: https://tetrate.io/blog/deciphering-istio-multi-cluster-authentication-mtls-connection/