addressing pr comments

secret-injector/README.md

@@ -5,37 +5,31 @@ The 1Password Secrets Injector implements a mutating webhook to inject 1Password
 The 1Password Secrets Injector for Kubernetes can be used in conjuction with the 1Password Kubernetes Operator in order to provide automatic deployment restarts when a 1Password item being used by your deployment has been updated.
 
 
-[Click here for more details on the 1Password Kubernetes Operator](operator/README.md)
+[Click here for more details on the 1Password Kubernetes Operator](../operator/README.md)
 
 ## Setup and Deployment
 
-The 1Password Secrets Injector for Kubernetes uses a webhook server in order to inject secrets into pods and deployments. Admission to the webhook server is needs to be s secure operation, thus communication with the webhook server requires a TLS certificate signed by a Kubernetes CA.
+The 1Password Secrets Injector for Kubernetes uses a webhook server in order to inject secrets into pods and deployments. Admission to the webhook server must be a secure operation, thus communication with the webhook server requires a TLS certificate signed by a Kubernetes CA.
 
-For a simple setup we suggest using s script by morvencao for [creating a signed cert for the webook](https://github.com/morvencao/kube-mutating-webhook-tutorial/blob/master/deploy/webhook-create-signed-cert.sh). A copy of this script can also be found in this repo [here](secret-injector/deploy/webhook-create-signed-cert.sh).
+For managing TLS certifcates for your cluster please see the [official documentation](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/). The certificate and key generated in the offical documentation must be set in the [deployment](deploy/deployment.yaml) arguments (`tlsCertFile` and `tlsKeyFile` respectively) for the Secret injector.
 
-Run the script with the following:
-```
-./deploy/webhook-create-signed-cert.sh \
-    --service <name of webhook service> \
-    --secret <name of kubernetes secret where certificate will be stored> \
-    --namespace <your namespace>
-```
-This will genrate a Kubernetes Secret with your signed certificate.
+In additon to setting the tlsCert and tlsKey for the Secret Injector service, we must also create a webhook configuration  for the service. An example of the confiugration can be found [here](deploy/mutatingwebhook.yaml). In the provided example you may notice that the caBundle is not set. Please replace this value with your caBundle. This can be generated with the Kubernetes apiserver's default caBundle with the following command
 
-Next we must set the webhook configuration. An example of this configuration can be found [here](secret-injector/deploy/mutatingwebhook.sh). If you choose to use this example, replace `${CA_BUNDLE}`  file's with the value stored for `client-ca-file` in the Kubernetes Secret you generated in the previous step. 
+```export CA_BUNDLE=$(kubectl get configmap -n kube-system extension-apiserver-authentication -o=jsonpath='{.data.client-ca-file}' | base64 | tr -d '\n')```
 
 ```
 apiVersion: admissionregistration.k8s.io/v1beta1
 kind: MutatingWebhookConfiguration
 metadata:
-  name: op-secret-injector-webhook-cfg
+  name: op-secret-injector-webhook-config
   labels:
     app: op-secret-injector
 webhooks:
-- name: op-secret-injector.morven.me
+- name: op-secret-injector.1password
+  failurePolicy: Fail
   clientConfig:
     service:
-      name: op-secret-injector-webhook-svc
+      name: op-secret-injector-webhook-service
       namespace: op-secret-injector
       path: "/inject"
     caBundle: ${CA_BUNDLE} //replace this with your own CA Bundle
@@ -75,6 +69,8 @@ kubectl label namespace <namespace> op-secret-injection=enabled
 
 To inject a 1Password secret as an environment variable, your pod or deployment you must add an environment variable to the resource with a value referencing your 1Password item in the format `op://<vault>/<item>[/section]/<field>`. You must also annotate your pod/deployment spec with `operator.1password.io/inject` which expects a comma separated list of the names of the containers to that will be mutated and have secrets injected.
 
+Note: You must also include the command needed to run the container as the secret injector prepends a script to this command in order to allow for secret injection.
+
 ```
 #example
 
@@ -96,6 +92,7 @@ spec:
       containers:
         - name: app-example
           image: my-image
+          command: ["./example"]
           env:
           - name: DB_USERNAME
             value: op://my-vault/my-item/sql/username
@@ -116,16 +113,11 @@ spec:
           - name: DB_PASSWORD
             value: op://my-vault/my-item/sql/password
 ```
-
-## Attributions
-
-This project is based on and heavily inspired by [morvencao's Kubernetes Mutating Webhook for Sidecar Injection tutorial](https://github.com/morvencao/kube-mutating-webhook-tutorial).
-
 ## Troubleshooting
 
-Sometimes you may find that pod is injected with sidecar container as expected, check the following items:
+If you are trouble getting secrets injected in your pod, check the following:
 
-1. The sidecar-injector webhook is in running state and no error logs.
-2. The namespace in which application pod is deployed has the correct labels as configured in `mutatingwebhookconfiguration`.
-3. Check the `caBundle` is patched to `mutatingwebhookconfiguration` object by checking if `caBundle` fields is empty.
-4. Check if the application pod has annotation `sidecar-injector-webhook.morven.me/inject":"yes"`.
+1. Check that that the namespace of your pod has the `op-secret-injection=enabled` label
+2. Check that the `caBundle` in `mutatingwebhookconfiguration.yaml` is set with a correct value
+3. Ensure that the 1Password Secret Injector webhook is running (`op-secret-injector` by default).
+4. Check that your container has a `command` field specifying the command to run the app in your container