/docs/tasks/security/dns-cert/index.md

[SataQiu]

Source File: /docs/tasks/security/dns-cert/index.md
Diff:

 diff --git a/content/en/docs/tasks/security/dns-cert/index.md b/content/en/docs/tasks/security/dns-cert/index.md
index 0462797a0..18859c2f8 100644
--- a/content/en/docs/tasks/security/dns-cert/index.md
+++ b/content/en/docs/tasks/security/dns-cert/index.md
@@ -5,44 +5,32 @@ weight: 90
 keywords: [security,certificate]
 ---
 
-{{< boilerplate experimental-feature-warning >}}
+This task shows how to provision and manage DNS certificates
+using [Chiron](/blog/2019/dns-cert/), a lightweight component linked with Istiod that signs certificates
+using the Kubernetes CA APIs without maintaining its own private key.
+Using this feature has the following advantages:
 
-By default, the DNS certificates used by the webhooks of Galley and the sidecar
-injector are provisioned and managed by Citadel, which is a large component
-that maintains its own signing key and also acts as a CA for Istio.
+* Unlike {{< gloss >}}Istiod{{< /gloss >}}, this feature doesn't require maintaining a private signing key, which enhances security.
 
-In certain deployments, you may want to use your own certificate authority
-instead of Citadel. In those cases, Citadel ends up being used strictly for
-its DNS certificate provisioning functionality. Rather than having to deploy
-Citadel at all in this case, you can instead leverage Chiron, a lightweight
-component linked with Pilot that signs certificates using the Kubernetes CA APIs without maintaining its own private key.
-
-This task shows how to provision and manage DNS certificates for Istio control
-plane components through Chiron. Using this feature has the following advantages:
-
-* More lightweight than Citadel.
-
-* Unlike Citadel, this feature doesn't require maintaining a private signing key, which enhances security.
-
-* Simplified root certificate distribution to TLS clients. Clients no longer need to wait for Citadel to generate and distribute its CA certificate.
+* Simplified root certificate distribution to TLS clients. Clients no longer need to wait for Istiod to generate and distribute its CA certificate.
 
 ## Before you begin
 
 * Install Istio through `istioctl` with DNS certificates configured.
-The configuration is read when Pilot starts.
+The configuration is read when Istiod starts.
 
 {{< text bash >}}
 $ cat <<EOF > ./istio.yaml
-apiVersion: install.istio.io/v1alpha2
-kind: IstioControlPlane
+apiVersion: install.istio.io/v1alpha1
+kind: IstioOperator
 spec:
   values:
     global:
       certificates:
-        - secretName: dns.istio-galley-service-account
-          dnsNames: [istio-galley.istio-system.svc, istio-galley.istio-system]
-        - secretName: dns.istio-sidecar-injector-service-account
-          dnsNames: [istio-sidecar-injector.istio-system.svc, istio-sidecar-injector.istio-system]
+        - secretName: dns.example1-service-account
+          dnsNames: [example1.istio-system.svc, example1.istio-system]
+        - secretName: dns.example2-service-account
+          dnsNames: [example2.istio-system.svc, example2.istio-system]
 EOF
 $ istioctl manifest apply -f ./istio.yaml
 {{< /text >}}
@@ -67,19 +55,19 @@ store the certificate and the key.
 After configuring Istio to generate DNS certificates and storing them in secrets
 of your choosing, you can verify that the certificates were provisioned and work properly.
 
-To check that Istio generated the `dns.istio-galley-service-account` DNS certificate as configured in the example,
+To check that Istio generated the `dns.example1-service-account` DNS certificate as configured in the example,
 and that the certificate contains the configured DNS names, you need to get the secret from Kubernetes, parse it,
 decode it, and view its text output with the following command:
 
 {{< text bash >}}
-$ kubectl get secret dns.istio-galley-service-account -n istio-system -o json | jq -r '.data["cert-chain.pem"]' | base64 --decode | openssl x509 -in /dev/stdin -text -noout
+$ kubectl get secret dns.example1-service-account -n istio-system -o json | jq -r '.data["cert-chain.pem"]' | base64 --decode | openssl x509 -in /dev/stdin -text -noout
 {{< /text >}}
 
 The text output should include:
 
 {{< text plain >}}
 X509v3 Subject Alternative Name:
-  DNS:istio-galley.istio-system.svc, DNS:istio-galley.istio-system
+  DNS:example1.istio-system.svc, DNS:example1.istio-system
 {{< /text >}}
 
 ## Regenerating a DNS certificate
@@ -90,7 +78,7 @@ we show how you can delete a recently configured certificate and verify Istio re
 1. Delete the secret storing the DNS certificate configured earlier:
 
     {{< text bash >}}
-    $ kubectl delete secret dns.istio-galley-service-account -n istio-system
+    $ kubectl delete secret dns.example1-service-account -n istio-system
     {{< /text >}}
 
 1. To check that Istio regenerated the deleted DNS certificate, and that the certificate
@@ -98,12 +86,12 @@ contains the configured DNS names, you need to get the secret from Kubernetes, p
 and view its text output with the following command:
 
     {{< text bash >}}
-    $ kubectl get secret dns.istio-galley-service-account -n istio-system -o json | jq -r '.data["cert-chain.pem"]' | base64 --decode | openssl x509 -in /dev/stdin -text -noout
+    $ kubectl get secret dns.example1-service-account -n istio-system -o json | jq -r '.data["cert-chain.pem"]' | base64 --decode | openssl x509 -in /dev/stdin -text -noout
     {{< /text >}}
 
 The output should include:
 
 {{< text plain >}}
 X509v3 Subject Alternative Name:
-  DNS:istio-galley.istio-system.svc, DNS:istio-galley.istio-system
+  DNS:example1.istio-system.svc, DNS:example1.istio-system
 {{< /text >}}