Generating Istio certificates
Generate and provide Istio root CA and intermediate CA certificates in your Gloo Mesh setup so that each Istio deployment can issue certificates to workload pods in its mesh. You can choose from the following options:
- Use built-in Istio tools to generate root CA and intermediate CA certificates
- Create a root CA and intermediate CA for Istio, such as to use in your own public key infrastructure (PKI) to automate root and intermediate certificates
- Manually provide your own root CA and intermediate CA certificates and store them as Kubernetes secrets in each workload cluster
Using Istio tools to generate root CA and intermediate CA certificates
Istio provides a certificate tool that you can use to quickly generate the root CA and intermediate CA certificates for Istio deployments in each cluster.
-
Switch to the management cluster context.
kubectl config use-context $MGMT_CONTEXT
-
Download Istio in the management cluster. Make sure to use a supported version that matches the version you plan to run in the workload clusters.
ISTIO_VERSION=1.13.4 curl -L https://istio.io/downloadIstio | ISTIO_VERSION=$ISTIO_VERSION sh -
-
Set the variables for each CA that you can override when generating your certificates. For the full list of variables, see the following example
root-ca.conf
.#------------------------------------------------------------------------ # variables: root CA ROOTCA_DAYS ?= 3650 ROOTCA_KEYSZ ?= 4096 ROOTCA_ORG ?= Istio ROOTCA_CN ?= Root CA KUBECONFIG ?= $(HOME)/.kube/config ISTIO_NAMESPACE ?= istio-system #------------------------------------------------------------------------ # variables: intermediate CA INTERMEDIATE_DAYS ?= 730 INTERMEDIATE_KEYSZ ?= 4096 INTERMEDIATE_ORG ?= Istio INTERMEDIATE_CN ?= Intermediate CA INTERMEDIATE_SAN_DNS ?= istiod.istio-system.svc
-
Generate the root certificate.
# Go to certs directory cd istio-$ISTIO_VERSION/tools/certs # Create root certificate make -f Makefile.selfsigned.mk \ ROOTCA_CN="Solo Root CA" \ ROOTCA_ORG=solo.io \ root-ca # If needed, delete certs # make -f Makefile.selfsigned.mk clean
-
Generate the intermediate CA certificate for the relay agent in a workload cluster. Repeat this step for each workload cluster you plan to register with Gloo Mesh.
REMOTE_CLUSTER1=<remote-cluster-1-name> REMOTE_CONTEXT1=<remote-cluster-1-context> make -f Makefile.selfsigned.mk \ INTERMEDIATE_CN="Solo Intermediate CA" \ INTERMEDIATE_ORG=solo.io \ $REMOTE_CLUSTER1-cacerts # Apply Kubernetes secret to cluster kubectl create secret generic cacerts --context $REMOTE_CONTEXT1 -n istio-system \ --from-file=$REMOTE_CLUSTER1/ca-cert.pem \ --from-file=$REMOTE_CLUSTER1/ca-key.pem \ --from-file=$REMOTE_CLUSTER1/root-cert.pem \ --from-file=$REMOTE_CLUSTER1/cert-chain.pem
Creating root and intermediate CAs to generate certificates
To create CAs in your own PKI infrastructure, you can use these example configurations as a starting point for a root and intermediate CAs that can generate Istio intermediate CA certificates with the same root for each workload cluster.
# Root CA example configuration
cat > "root-ca.conf" <<EOF
[ req ]
encrypt_key = no
prompt = no
utf8 = yes
default_md = sha256
default_bits = 4096
req_extensions = req_ext
x509_extensions = req_ext
distinguished_name = req_dn
[ req_ext ]
subjectKeyIdentifier = hash
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, nonRepudiation, keyEncipherment, keyCertSign
[ req_dn ]
O = Istio
CN = Root CA
EOF
# Istio intermediate signing CA example configuration
cat > "cluster-ca.conf" <<EOF
[ req ]
encrypt_key = no
prompt = no
utf8 = yes
default_md = sha256
default_bits = 4096
req_extensions = req_ext
x509_extensions = req_ext
distinguished_name = req_dn
[ req_ext ]
subjectKeyIdentifier = hash
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, nonRepudiation, keyEncipherment, keyCertSign
subjectAltName=@san
[ san ]
DNS.1 = istiod.istio-system.svc
[ req_dn ]
O = Istio
CN = Intermediate CA
L = ${cluster}
EOF
Manually providing Istio root CA and intermediate CA certificates
You can bring your own signing certificates and store them as Kubernetes secrets within each workload cluster. Note that adding automation to create and rotate these certificates, such as using AWS Certificate Manager (ACM), is recommended.
The name of the secret must be cacerts
, and it must be created in the istio-system
namespace of each workload cluster. The files in the secret must be named in the same format as the following.
# Example kubectl apply (file names are important)
# ca-cert.pem
# ca-key.pem
# root-cert.pem
# cert-chain.pem
kubectl create secret generic cacerts -n istio-system \
--from-file=ca-cert.pem=istio-ca/cert.pem \
--from-file=ca-key.pem=istio-ca/ca.key.decrypted \
--from-file=root-cert.pem=root-ca/ca.crt \
--from-file=cert-chain.pem=istio-ca/cert-chain.pem
Rotating certificates for Istio workloads
When certificates are issued, pods that are managed by Istio must be restarted to ensure they pick up the new certificates. The certificate issuer creates a PodBounceDirective, which contains the namespaces and labels of the pods that must be restarted. For more information about how certificate rotation works in Istio, review the video series in this blog post.
Note: To avoid potential downtime for your apps in production, disable the PodBounceDirective feature. Then, control pod restarts in another way, such as a rolling update.
-
Get your root trust policies.
kubectl get roottrustpolicy --context ${MGMT_CONTEXT} -A
-
In the root trust policy, set the
autoRestartPods
field tofalse
.kubectl edit roottrustpolicy --context ${MGMT_CONTEXT} -n NAMESPACE ROOT_TRUST_POLICY
apiVersion: admin.gloo.solo.io/v2 kind: RootTrustPolicy metadata: name: north-south-gw namespace: gloo-mesh spec: config: autoRestartPods: false ...
-
To ensure pods pick up the new certificates, restart the
istiod
pod in each remote cluster.kubectl --context {$REMOTE_CONTEXT} -n istio-system patch deployment istiod \ -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"date\":\"`date +'%s'`\"}}}}}"
-
Restart your app pods that are managed by Istio, such as by using a rolling update strategy.