re-work

documentation/installation.md

@@ -37,20 +37,19 @@ To check if the controller is working, find it in the list of kyverno pods:
 The [Kyverno CLI](documentation/testing-policies-cli.md) allows you to write and test policies without installing Kyverno in a Kubernetes cluster.
 
 # Pre-Requisites
-## Configure controller manager certificate signer
-When the cluster ca & key is not passed as arguments(mostly for in-cluster mode), the TLS communication between admission webhook and api-server requires a certificate signer configured. The certificate signer issues a certificate to a certificate signing request(CSR) generated by Kyverno, while generating TLS cert & key pair for webhook server.
+Kyverno installs an admission webhook that requires a CA-signed certificate and key to setup TLS communication with the kube-apiserver. In-cluster mode, there are 2 ways to configure the admission webhook TLS configuration:
+* Kyverno generates certificate and key pair for user, and a signed certificate is issued against the certificate signing request generated by Kyverno. This setup requires a 'certificate signer' configured in the cluster. The kube-controller-manager provides a default implementation of a signer which can be used to issue certificates. To verify if it is enabled, check if the command args `--cluster-signing-cert-file` and `--cluster-signing-key-file` are passed to the controller manager with paths to your CA's key-pair.
+* Use self-signed certificates.
 
-The Kubernetes controller manager provides a default implementation of a signer. To verify if it is enabled, check if the command args `--cluster-signing-cert-file` and `--cluster-signing-key-file` are passed to the controller manager with paths to your Certificate Authority’s keypair by checking pod YAML for api-server.
-
-## Use self-signed certificates to test kyverno.
-To create root CA and generate certificate & key pair using it via openssl:
+## Use self-signed certificates
+To create a root CA, generate signed certificate and key using openssl:
 1. `openssl genrsa -out rootCA.key 4096`
 2. `openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt  -subj "/C=US/ST=test/L=test /O=test /OU=PIB/CN=*.kyverno.svc/emailAddress=test@test.com”`
 3. `openssl genrsa -out webhook.key 4096`
 4. `openssl req -new -key webhook.key -out webhook.csr  -subj "/C=US/ST=test /L=test /O=test /OU=PIB/CN=kyverno-svc.kyverno.svc/emailAddress=test@test.com"`
 5. `openssl x509 -req -in webhook.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out webhook.crt -days 1024 -sha256`
 
-the following generated files are used to create secrets:
+the following files are generated and are used to create kubernetes secrets:
 - rootCA.crt
 - webhooks.crt
 - webhooks.key	
@@ -65,9 +64,9 @@ Secret | Data | Content
 `tls.ca` | rootCA.crt | root CA used to sign the certificate
 `tls.kyverno` | tls.key & tls.crt  | key and signed certificate
 
-Here, we create the project namespace ‘kyverno’, followed by secrets for CA and TLS pair(cert,key). If the above secrets are defined then the kyverno Webhooks would use these to define the TLS pair for web server and CA bundle used to validate the webhook's server certificate in the Mutating/Validating Webhooks configuration.
+Kyverno uses secrets created above to define the TLS configuration for the webserver hook and specify the CA bundle used to validate the webhook's server certificate in the admission webhook configurations.
 
-To deploy the kyverno project, run `kubectl create -f definitions/install.yaml`. You can ignore the error 'namespaces "kyverno" already exists', as we have already created the namespace 'kyverno' while defining the secrets the previous step.
+To deploy the Kyverno project, run `kubectl create -f definitions/install.yaml`. You can ignore the error 'namespaces "kyverno" already exists', which occurs as we previously created the namespace while creating the secrets.
 
 ---
 <small>*Read Next >> [Writing Policies](/documentation/writing-policies.md)*</small>