Integrating with istio helm chart installs

[sepulworld]

Does anyone have any example values inputs when integrating istio-csr with an istio setup installed using Helm https://istio.io/latest/docs/setup/install/helm/

I see istio-csr refers to this https://github.com/cert-manager/istio-csr/blob/main/hack/istio-config-1.10.0.yaml but does anyone have a translation of this to the istio helm chart install?

[keithmattix]

Bumping this: IstioOperator is now discouraged. It would be great to have some instructions for how to set this up with native Helm

[ajp-lsq]

Third bump, trying to figure this out right now.

In case anyone else is working on this, what I've found so far is .global.mountMtlsCerts in the istio/istiod helm chart (version 1.13.0 at least). Looks like this affects files/gen-istio.yaml in the istiod helm chart, mounting volumes and volume mounts as such:

          {{- if .Values.global.mountMtlsCerts }}
          # Use the key and cert mounted to /etc/certs/ for the in-cluster mTLS communications.
          - name: istio-certs
            secret:
              optional: true
              {{ if eq .Spec.ServiceAccountName "" }}
              secretName: istio.default
              {{ else -}}
              secretName: {{  printf "istio.%s" .Spec.ServiceAccountName }}
              {{  end -}}
          {{- end }}

            {{- if .Values.global.mountMtlsCerts }}
            # Use the key and cert mounted to /etc/certs/ for the in-cluster mTLS communications.
            - mountPath: /etc/certs/
              name: istio-certs
              readOnly: true
            {{- end }}

It does the same thing in files/gateway-injection-template.yaml and files/injection-template.yaml.

I'm not sure which secret this is in relation to the changes in the IstioOperator resource. It doesn't really look like it applies to either? Unfortunately, it doesn't seem the chart allows for definition of arbitrary extra volumes either. EDIT: I think this could be pulled off as is? The istio-csr chart deploys a certificate called istiod-tls that will have the end entity cert for istiod, and may have the root cert in it as well. Nevermind, but nearly. The certificate deployed by istio-csr has a statically set name of istiod-tls. The chart statically defines cacerts for its custom root. The chart will have to be modified to accomodate the new secret from istio-csr.

Other than that caAddress and trustDomain can both be changed by the chart, and you can define custom envs to set ENABLE_CA_SERVER to false.

[ajp-lsq]

As an FYI for anyone coming across this issue, it's actually a fairly simple fix to work with the Istio helm chart. I'm working on PR'ing these changes to the upstream chart, but here are the general instructions:

1. Add the following to the container args for istiod:

          - "--tlsCertFile=/etc/tls-identity/tls.crt"
          - "--tlsKeyFile=/etc/tls-identity/tls.key"
          - "--caCertFile=/etc/tls-root-ca/root-cert.pem"

2. Add the following to the volume mounts for istiod:

          # Only add custom TLS client and CA certs if vault pki enabled
          # istio-csr: mount cert-managed issued end-entity cert
          - name: tls-identity
            mountPath: /etc/tls-identity
            readOnly: true
          # istio-csr: mount root ca cert
          - name: tls-root-ca
            mountPath: /etc/tls-root-ca
            readOnly: true

3. Add the following to the volumes for istiod:

      # Only add custom TLS client and CA certs if vault pki enabled
      # istio-csr: mount cert-manager issued end-entity cert
      - name: tls-identity
        secret:
          secretName: istiod-tls
      # istio-csr: mount root ca cert
      - name: tls-root-ca
        configMap:
          defaultMode: 420
          name: istio-ca-root-cert

4. Set the following values in istiod's chart's values file: pilot.env.ENABLE_CA_SERVER="false", global.caAddress="cert-manager-istio-csr.cert-manager.svc:443"

The tls-identity volume and mount will take care of loading the mTLS certificate deployed for istiod by the cert-manager-istio-csr chart. The tls-root-ca volume and mount will load the root cert from a configmap created in every namespace by the cert-manager-istio-csr pod (this configmap is populated when the pod first boots, using the CA cert it has been provided). The args edit will take care of pointing istiod to those identity and CA certs, and the values.yaml change will ensure that CSR requests are forward to the cert-manager-istio-csr pod, not istiod.

[sepulworld]

Thank you @ajp-lsq and others for notes!

I use Terraform for istiod and istio-base Helm installs. Ill add support for this in the module I open sourced

Terraform Registry terraform-helm-istio
Github terraform-helm-istio

[sepulworld]

@ajp-lsq can you ping us here when you have PR on upstream chart or reference this issue in PR? Thanks for the help!

[ceastman-r7]

@ajp-lsq I am also interested in this work. Thank you.

[tabnul]

ajp-lsq

Did you allready PR your changes to the upstream project?
Thanks!

[sabinayakc]

@ajp-lsq @sepulworld were you able to make any progress on the terraform module and/or helm chart?

I am on the same boat. Trying to use helm and use AWS Private CA with Istio.

[tomreeb]

Hi everyone, as the above PR for Istio has been merged, we can now override helm values to integrate with cert-manager a little easier:

  # Additional container arguments
  extraContainerArgs:
    - --tlsCertFile=/etc/cert-manager/tls/tls.crt
    - --tlsKeyFile=/etc/cert-manager/tls/tls.key
    - --caCertFile=/etc/cert-manager/ca/root-cert.pem

  env: 
    ENABLE_CA_SERVER: false

  # Additional volumeMounts to the istiod container
  volumeMounts:
    - mountPath: /etc/cert-manager/tls
      name: cert-manager
      readOnly: true
    - mountPath: /etc/cert-manager/ca
      name: istio-csr-ca-configmap
      readOnly: true

  # Additional volumes to the istiod pod
  volumes: []
    - name: cert-manager
      secret:
        defaultMode: 420
        secretName: istiod-tls
    - configMap:
        defaultMode: 420
        name: istio-ca-root-cert
        optional: true
      name: ca-root-cert

[cm3brian]

I'm kinda confused here, as a person moving from istio-operator to istio helm, it seems that this "issue" was handled some time ago with a "zero config" solution here: istio/istio#39375

Can someone explain if/why this does not work? as I would think the "zero-config" route makes sense with just leveraging known paths mounts for secrets?

I'll be progressing into testing in the near future so I'll also report back my own findings here.

[volodymyr-mykhailyk]

I'm kinda confused here, as a person moving from istio-operator to istio helm, it seems that this "issue" was handled some time ago with a "zero config" solution here: istio/istio#39375

Can someone explain if/why this does not work? as I would think the "zero-config" route makes sense with just leveraging known paths mounts for secrets?

I'll be progressing into testing in the near future so I'll also report back my own findings here.

Just deployed istio in staging with the "zero config" - and it simply works.
In my deployment, there are:

• custom Issuer named istio-ca in istio-system namespace that can generate certificate using vault
• no special configuration for istio-csr helm
• istio helm chart has CA server disabled and caAddress set to istio-csr module:

  global:
    caAddress: cert-manager-istio-csr.cert-manager.svc:443
  pilot:
    env:
      ENABLE_CA_SERVER: false

So I suspect there have been two initiatives in parallel to solve this problem from different ends. One that you mentioned istio/istio#39375 and one istio/istio#45517 that @tomreeb has contributed to the istio recently.

Now someone just needs to update the documentation so one or both are easier to use

[brettcurtis]

@volodymyr-mykhailyk : I'm curious if this zero config method still works or if these docs are the way it has to be?

[cm3brian]

I can confirm from my own experience, that the zero config version works still/fine. It never presented any hindrance and "just worked". We implemented it prior to the helpful instructions posted by @volodymyr-mykhailyk by interrogating the helm chart vs our existing istio-operator deployment.

[brettcurtis]

Thanks! I was able to test as well. I did need to set app.server.clusterId, but other than that, I was good.