How to manage Certification using Istio for Kubernetes Cluster -1

Reading Time: 5 minutes


manage certificate using istio

This blog is similar to previous blog where we explored service mesh configuration using User Interface. Here, we will see how istio is able to manage certification for cluster. Since it was a long topic we will cover the external certification addition part in Part 2.

Terms to be known

  • Registration Authority(RA): key role to approve requests and sign the request if valid.
  • Certification Authority(CA): signing workload requests after RA approves it.
  • Public Key Infrastructure (PKI): a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption.
  • Certificate Signing Request (CSR): a specially formatted encrypted message sent from a Secure Sockets Layer (SSL) digital certificate applicant to a certificate authority (CA).

Istiod works as both RA and CA. Istio manages certificates by istiod itself.

Installation of Istio with CA plugin

For istio profile=default configuration

$ istioctl install --set profile=default -y
ile=default -y
✔ Istio core installed                                                                              
✔ Istiod installed                                                                                  
✔ Ingress gateways installed                                                                        
✔ Installation complete                                                                             Making this installation the default for injection and validation.

Thank you for installing Istio 1.14.  Please take a few minutes to tell us about your install/upgrade experience!

This installs istio core , istiod, istio ingress gateway on the cluster within the namespace istio-system. You can check it in following way:

$ kubectl get all -n istio-system
NAME                                        READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-5f86977657-cqv56   1/1     Running   0          72s
pod/istiod-7587989b4f-6s9w5                 1/1     Running   0          112s

NAME                           TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
service/istio-ingressgateway   LoadBalancer    <pending>     15021:30723/TCP,80:30373/TCP,443:30929/TCP   70s
service/istiod                 ClusterIP   <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP        110s

NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/istio-ingressgateway   1/1     1            1           72s
deployment.apps/istiod                 1/1     1            1           112s

NAME                                              DESIRED   CURRENT   READY   AGE
replicaset.apps/istio-ingressgateway-5f86977657   1         1         1       72s
replicaset.apps/istiod-7587989b4f                 1         1         1       112s

NAME                                                       REFERENCE                         TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
horizontalpodautoscaler.autoscaling/istio-ingressgateway   Deployment/istio-ingressgateway   <unknown>/80%   1         5         1          71s
horizontalpodautoscaler.autoscaling/istiod                 Deployment/istiod                 <unknown>/80%   1         5         1          111s

istiod search for CA cert secret exists in istio-system

if not itself generates ca certificate for it

  • recommendation : use your own PKI

How self signed certification in Istio works ?

  1. find it namespace istio-system
$ kubectl get secret -n istio-system
NAME              TYPE               DATA   AGE
istio-ca-secret   5      60m

$ kubectl get cm -n istio-system
NAME                                  DATA   AGE
istio                                 2      61m
istio-ca-root-cert                    1      60m
istio-gateway-deployment-leader       0      60m
istio-gateway-status-leader           0      60m
istio-leader                          0      60m
istio-namespace-controller-election   0      60m
istio-sidecar-injector                2      61m
kiali                                 1      58m
kube-root-ca.crt                      1      61m
prometheus                            5      58m

istio-ca-root-cert configmap created

  1. explore its contents
$ kubectl get cm istio-ca-root-cert -o json | jq '[.data[]][0]' -r | openssl x509 -noout -text
Version: 3 (0x2)
Serial Number:
Signature Algorithm: sha256WithRSAEncryption
Issuer: O = cluster.local
Not Before: Aug  4 07:01:44 2022 GMT
Not After : Aug  1 07:01:44 2032 GMT
Subject: O = cluster.local
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign
X509v3 Basic Constraints: critical
X509v3 Subject Key Identifier:
Signature Algorithm: sha256WithRSAEncryption
Signature Value:

created by local system and valid for 10 years.
used RSA 256 algorithm with its own pki here.

Trust Distribution

  • istiod copies the config map istio-ca-root-cert to every namespace created in k8s cluster.
  • services use these cert for mutual TLS and request RBAC.
$ kubectl get cm -A -l
NAMESPACE      NAME                 DATA   AGE
default        istio-ca-root-cert   1      70m
devops         istio-ca-root-cert   1      70m
istio-system   istio-ca-root-cert   1      70m

$ kubectl create ns demo
namespace/demo created
$ kubectl get cm -A -l
NAMESPACE      NAME                 DATA   AGE
default        istio-ca-root-cert   1      71m
demo           istio-ca-root-cert   1      10s
devops         istio-ca-root-cert   1      71m
istio-system   istio-ca-root-cert   1      71m

it does not require to enble istio injection
it is smart to not copy this config map in basic namespaces like kube-system

$ kubectl get ns
NAME              STATUS   AGE
default           Active   79m
demo              Active   4m24s
devops            Active   75m
istio-system      Active   76m
kube-node-lease   Active   79m
kube-public       Active   79m
kube-system       Active   79m
  • The moment the services are created in the namespace and sidecars are injected; the injector mounts the istio cert to istio agent and proxy as well to provide access to root cert.
  • Istio-agent genrates a private key and sends CSR (Certificate Signing Requests) to Istiod.
  • Istiod generates a private key in memory and this key never leaves the pod
  • the certifiate expires in 24 hours
  • but is renewed every 12 hours
  • Configuration is done by pilot-agent env var:
  • SECRET_GRACE_PERIOD_RATIO (default is 0.5)

CA Certs : Custom

  1. In the top-level directory of the Istio installation package, create a directory to hold certificates and keys:
$ mkdir -p certs
$ pushd certs
  1. Generate the root certificate and key:
$ make -f ../tools/certs/ root-ca

This will generate the following files:

  • root-cert.pem: the generated root certificate
  • root-key.pem: the generated root key
  • root-ca.conf: the configuration for openssl to generate the root certificate
  • root-cert.csr: the generated CSR for the root certificate
  1. For each cluster, where you want to use the istio service mesh separately, generate an intermediate certificate and key for the Istio CA. The following is an example for cluster1:
$ make -f ../tools/certs/ cluster1-cacerts

This will generate the following files in a directory named cluster1:

  • ca-cert.pem: the generated intermediate certificates
  • ca-key.pem: the generated intermediate key
  • cert-chain.pem: the generated certificate chain which is used by istiod
  • root-cert.pem: the root certificate

You can replace cluster1 with a string of your choice.

If you are doing this on an offline machine, copy the generated directory to a machine with access to the clusters.

  1. In each cluster, create a secret cacerts including all the input files ca-cert.pem, ca-key.pem, root-cert.pem and cert-chain.pem. For example, for cluster1:
$ kubectl create namespace istio-system
$ kubectl create secret generic cacerts -n istio-system \
--from-file=cluster1/ca-cert.pem \
--from-file=cluster1/ca-key.pem \
--from-file=cluster1/root-cert.pem \
  1. Return to the top-level directory of the Istio installation:
$ popd

Now when you install istio in the cluster, Istiod would not create its own certificates.

Certification Verification

To verify its working we need to deploy istio and run some services for certificates to be generated.


1. Deploy Istio using the demo profile.

Istio’s CA will read certificates and key from the secret-mount files.

$ istioctl install --set profile=demo

2. Running an example service

Note: Since we have not enabled the injection the side cars are injected directly via kubectl

  • Deploy the httpbin and sleep sample services.
$ kubectl create ns foo
$ kubectl apply -f &lt;(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n foo
$ kubectl apply -f &lt;(istioctl kube-inject -f samples/sleep/sleep.yaml) -n foo
  • Deploy a policy for workloads in the foo namespace to only accept mutual TLS traffic.
$ kubectl apply -n foo -f - &lt;<eof apiversion:="""" v1beta1="" kind:="" peerauthentication="" metadata:="" name:="" "default"="" spec:="" mtls:="" mode:="" strict="" eof="" ```="" ####="" 3.="" verification="" of="" the="" certificates="" we="" will="" verify="" that="" workload="" are="" signed="" by="" plugged="" into="" ca.="" this="" requires="" to="" have="" **openssl**="" installed="" on="" machine.="" *="" sleep="" 20="" seconds="" for="" mtls="" policy="" take="" effect="" before="" retrieving="" certificate="" chain="" httpbin.="" ***as="" ca="" used="" here="" is="" self-signed,="" error:num="19:self" in="" error="" returned="" openssl="" command="" expected.***="" ```bash="" $="" 20;="" kubectl="" exec="" "$(kubectl="" get="" pod="" -l="" app="sleep" -n="" foo="" -o="" jsonpath="{})&quot;" -c="" istio-proxy="" --="" s_client="" -showcerts="" -connect=""""> httpbin-proxy-cert.txt
  • Parse the certificates on the certificate chain.
$ sed -n '/-----BEGIN CERTIFICATE-----/{:start /-----END CERTIFICATE-----/!{N;b start};/.*/p}' httpbin-proxy-cert.txt &gt; certs.pem
$ awk 'BEGIN {counter=0;} /BEGIN CERT/{counter++} { print &gt; "proxy-cert-" counter ".pem"}' &lt; certs.pem
  • Verify the root certificate is the same as the one specified by the administrator:
$ openssl x509 -in certs/cluster1/root-cert.pem -text -noout &gt; /tmp/root-cert.crt.txt
$ openssl x509 -in ./proxy-cert-3.pem -text -noout &gt; /tmp/pod-root-cert.crt.txt
$ diff -s /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txt
Files /tmp/root-cert.crt.txt and /tmp/pod-root-cert.crt.txt are identical
  • Verify the CA certificate is the same as the one specified by the administrator:
$ openssl x509 -in certs/cluster1/ca-cert.pem -text -noout &gt; /tmp/ca-cert.crt.txt
$ openssl x509 -in ./proxy-cert-2.pem -text -noout &gt; /tmp/pod-cert-chain-ca.crt.txt
$ diff -s /tmp/ca-cert.crt.txt /tmp/pod-cert-chain-ca.crt.txt
Files /tmp/ca-cert.crt.txt and /tmp/pod-cert-chain-ca.crt.txt are identical
  • Verify the certificate chain from the root certificate to the workload certificate:
$ openssl verify -CAfile &lt;(cat certs/cluster1/ca-cert.pem certs/cluster1/root-cert.pem) ./proxy-cert-1.pem
./proxy-cert-1.pem: OK



Written by 

Vaibhav Kumar is DevOps Engineer at Knoldus | Part of Nashtech with experience in AWS, Google Cloud, Azure cloud services. He has worked on Jenkins, Azure Pipelines, GitHub Actions, Teamcity CI/CD tools. He research of new techs and share the knowledge to our readers