docs: fix minor issues

docs/lens-extension/overview.md

@@ -1,5 +1,5 @@
 # Capsule extension for Lens
-With Capsule extension for [Lens](https://github.com/lensapp/lens), a cluster administrator can easly manage from a single pane of glass all resources of a Kubernetes cluster, including all the Tenants created through the Capsule Operator.
+With Capsule extension for [Lens](https://github.com/lensapp/lens), a cluster administrator can easily manage from a single pane of glass all resources of a Kubernetes cluster, including all the Tenants created through the Capsule Operator.
 
 ## Features
 Capsule extension for Lens provides these capabilities:
@@ -8,4 +8,4 @@ Capsule extension for Lens provides these capabilities:
 - See tenant details and change through the embedded Lens editor
 - Check Resources Quota and Budget at both the tenant and namespace level
 
-Please, see the [README](https://raw.githubusercontent.com/clastix/capsule-lens-extension/master/README.md) for details about installation of the Capsule Lens Extension.
+Please, see the [README](https://github.com/clastix/capsule-lens-extension) for details about the installation of the Capsule Lens Extension.

docs/operator/contributing.md

@@ -27,7 +27,7 @@ the CRDs manifests, as well the deep copy functions, require _Operator SDK_:
 the binary has to be installed into your `PATH`.
 
 ### Installing Kubebuilder
-With the latest release of OperatorSDK there's a more tightly integration with
+With the latest release of OperatorSDK there's a more tighten integration with
 Kubebuilder and its opinionated testing suite: ensure to download the latest
 binaries available from the _Releases_ GitHub page and place them into the
 `/usr/local/kubebuilder/bin` folder, ensuring this is also in your `PATH`.
@@ -97,7 +97,7 @@ You can check if Capsule is running tailing the logs:
 ```
 
 Since Capsule is built using _OperatorSDK_, logging is handled by the zap
-module: log verbosity of the Capsule controller can be increased by passing
+module: log verbosity of the Capsule controller can be increased passing
 the `--zap-log-level` option with a value from `1` to `10` or the
 [basic keywords](https://godoc.org/go.uber.org/zap/zapcore#Level) although
 it is suggested to use the `--zap-devel` flag to get also stack traces.
@@ -124,7 +124,7 @@ deployment.apps/capsule-controller-manager scaled
 > This is mandatory since Capsule uses Leader Election
 
 #### Providing TLS certificate for webhooks
-Next step is to replicate the same environment Capsule is expecting in the Pod,
+The next step is to replicate the same environment Capsule is expecting in the Pod,
 it means creating a fake certificate to handle HTTP requests.
 
 ``` bash
@@ -133,8 +133,8 @@ kubectl -n capsule-system get secret capsule-tls -o jsonpath='{.data.tls\.crt}'
 kubectl -n capsule-system get secret capsule-tls -o jsonpath='{.data.tls\.key}' | base64 -d > /tmp/k8s-webhook-server/serving-certs/tls.key
 ```
 
-> We're using the certificates generate upon first installation of Capsule:
-> it means the Secret will be populated at first start-up.
+> We're using the certificates generate upon the first installation of Capsule:
+> it means the Secret will be populated at the first start-up.
 > If you plan to run it locally since the beginning, it means you will require
 > to provide a self-signed certificate in the said directory.
 
@@ -242,10 +242,10 @@ A commit description is welcomed to explain more the changes: just ensure
 to put a blank line and an arbitrary number of maximum 72 characters long
 lines, at most one blank line between them.
 
-Please, split changes into several and documented small commits: this will help us to perform a better review. Commits must follow the the Conventional Commits Specification, a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with Semantic Versioning, by describing the features, fixes, and breaking changes made in commit messages. See [Conventional Commits Specification](https://www.conventionalcommits.org) to learn about Conventional Commits.
+Please, split changes into several and documented small commits: this will help us to perform a better review. Commits must follow the Conventional Commits Specification, a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with Semantic Versioning, by describing the features, fixes, and breaking changes made in commit messages. See [Conventional Commits Specification](https://www.conventionalcommits.org) to learn about Conventional Commits.
 
 > In case of errors or need of changes to previous commits,
 > fix them squashing to make changes atomic.
 
 ### Miscellanea
-Please, add a new single line at end of any file as current coding style.
+Please, add a new single line at end of any file as the current coding style.

docs/operator/getting-started.md

@@ -19,10 +19,10 @@ $ kubectl apply -f https://raw.githubusercontent.com/clastix/capsule/master/conf
 It will install the Capsule controller in a dedicated namespace `capsule-system`.
 
 ### Install with Helm Chart
-Please, refer to the instructions reported into the Capsule Helm Chart [README](https://github.com/clastix/capsule/blob/master/charts/capsule/README.md). 
+Please, refer to the instructions reported in the Capsule Helm Chart [README](https://github.com/clastix/capsule/blob/master/charts/capsule/README.md). 
 
 # Create your first Tenant
-In Capsule, a _Tenant_ is an abstraction to group togheter multiple namespaces in a single entity within a set of bundaries defined by the Cluster Administrator. The tenant is then assigned to a user or group of users who is called _Tenant Owner_.
+In Capsule, a _Tenant_ is an abstraction to group multiple namespaces in a single entity within a set of boundaries defined by the Cluster Administrator. The tenant is then assigned to a user or group of users who is called _Tenant Owner_.
 
 Capsule defines a Tenant as Custom Resource with cluster scope.
 
@@ -99,7 +99,7 @@ $ kubectl -n oil-development run nginx --image=docker.io/nginx
 $ kubectl -n oil-development get pods
 ```
 
-but limited to only your own namespaces:
+but limited to only your namespaces:
 
 ```
 $ kubectl -n kube-system get pods

docs/operator/managed-kubernetes/aws-eks.md

@@ -1,5 +1,5 @@
 # Capsule on AWS EKS
-This is an example how to install AWS EKS cluster and one user
+This is an example of how to install AWS EKS cluster and one user
 manged by Capsule.
 
 It is based on [Using IAM Groups to manage Kubernetes access](https://www.eksworkshop.com/beginner/091_iam-groups/intro/)

docs/operator/managed-kubernetes/overview.md

@@ -1,5 +1,5 @@
 # Capsule over Managed Kubernetes
-Capsule Operator can be easly installed on a Managed Kubernetes Service. Since in these services, you do not have access to the Kubernetes APIs Server, you should check with your service provider following pre-requisites:
+Capsule Operator can be easily installed on a Managed Kubernetes Service. Since in these services, you do not have access to the Kubernetes APIs Server, you should check with your service provider following pre-requisites:
 
 - the default `cluster-admin` ClusterRole is accessible 
 - the following Admission Webhooks are enabled on the APIs Server:
@@ -8,8 +8,6 @@ Capsule Operator can be easly installed on a Managed Kubernetes Service. Since i
     - ResourceQuota
     - MutatingAdmissionWebhook
     - ValidatingAdmissionWebhook
-    - PodSecurityPolicy (optional)
-- a CNI plugin with support for Network Policies can be used.
 
 * [AWS EKS](./aws-eks.md)
 * CoAKS - Capsule over Azure Kubernetes Service

docs/operator/monitoring.md

@@ -1,6 +1,6 @@
 # Monitoring Capsule
 
-The Capsule dashboard allows you to track the health and performance of Capsule manager and tenants, with particular attention to resources saturation, server responses and latencies.
+The Capsule dashboard allows you to track the health and performance of Capsule manager and tenants, with particular attention to resources saturation, server responses, and latencies.
 
 ## Requirements
 
@@ -76,7 +76,7 @@ making sure to select the correct Prometheus data source:
 
 ##### Description
 
-This section provides information about the medium time delay between manager client input, side effects and new state determination (reconciliation).
+This section provides information about the medium time delay between manager client input, side effects, and new state determination (reconciliation).
 
 ##### Dependant variables and available values
 
@@ -117,7 +117,7 @@ This section provides information about webhook requests response, mainly focusi
 
 ##### Description
 
-This section provides information about the medium time delay between webhook trigger, side effects and data written on etcd.
+This section provides information about the medium time delay between webhook trigger, side effects, and data written on etcd.
 
 ##### Dependant variables and available values
 
@@ -139,7 +139,7 @@ This section provides information about the medium time delay between webhook tr
 ##### Description
 
 This section provides information about the medium time delay between all the calls done by the controller and the API server.
-Data display may depends on the REST client verb considered and on available REST client URLs.
+Data display may depend on the REST client verb considered and on available REST client URLs.
 
 YMMV
 
@@ -175,7 +175,7 @@ This section provides information about resources, giving a detailed picture of
 
 ##### Description
 
-This section provides information about "actions" in queue, particularly:
+This section provides information about "actions" in the queue, particularly:
 - Workqueue latency: time to complete a series of actions in the queue ;
 - Workqueue rate: number of actions per unit time ;
 - Workqueue depth: number of pending actions waiting in the queue.

docs/operator/mtb/allow-self-service-management-of-network-policies.md

@@ -6,7 +6,7 @@
 
 **Category:** Self-Service Operations
 
-**Description:** Tenants should be able to perform self-service operations by creating own network policies in their namespaces.
+**Description:** Tenants should be able to perform self-service operations by creating their own network policies in their namespaces.
 
 **Rationale:** Enables self-service management of network-policies.
 
@@ -56,7 +56,7 @@ NAME            POD-SELECTOR   AGE
 capsule-oil-0   <none>         7m5s
 ```
 
-As tenant owner check for permissions to manage networkpolicy for each verb
+As a tenant, checks for permissions to manage networkpolicy for each verb
 
 ```bash 
 kubectl --kubeconfig alice auth can-i get networkpolicies

docs/operator/mtb/allow-self-service-management-of-rolebindings.md

@@ -6,7 +6,7 @@
 
 **Category:** Self-Service Operations
 
-**Description:** Tenants should be able to perform self-service operations by creating own rolebindings in their namespaces.
+**Description:** Tenants should be able to perform self-service operations by creating their rolebindings in their namespaces.
 
 **Rationale:** Enables self-service management of roles.
 

docs/operator/mtb/allow-self-service-management-of-roles.md

@@ -6,7 +6,7 @@
 
 **Category:** Self-Service Operations
 
-**Description:** Tenants should be able to perform self-service operations by creating own roles in their namespaces.
+**Description:** Tenants should be able to perform self-service operations by creating their own roles in their namespaces.
 
 **Rationale:** Enables self-service management of roles.
 
@@ -37,7 +37,7 @@ kubectl --kubeconfig alice create ns oil-production
 kubectl --kubeconfig alice config set-context --current --namespace oil-production
 ```
 
-As tenant owner check for permissions to manage roles for each verb
+As tenant owner, check for permissions to manage roles for each verb
 
 ```bash 
 kubectl --kubeconfig alice auth can-i get roles

docs/operator/mtb/block-access-to-cluster-resources.md

@@ -6,7 +6,7 @@
 
 **Category:** Control Plane Isolation
 
-**Description:** Tenants should not be able to view, edit, create, or delete cluster (non-namespaced) resources such Node, ClusterRole, ClusterRoleBinding, etc.
+**Description:** Tenants should not be able to view, edit, create or delete cluster (non-namespaced) resources such Node, ClusterRole, ClusterRoleBinding, etc.
 
 **Rationale:** Access controls should be configured for tenants so that a tenant cannot list, create, modify or delete cluster resources
 
@@ -53,7 +53,7 @@ kubectl --kubeconfig alice auth can-i create namespaces
 yes
 ```
 
-Any kubernetes user can create `SelfSubjectAccessReview` and `SelfSubjectRulesReviews` to checks whether he/she can perform an action. First two exceptions are not an issue.
+Any kubernetes user can create `SelfSubjectAccessReview` and `SelfSubjectRulesReviews` to checks whether he/she can act. First, two exceptions are not an issue.
 
 ```bash 
 kubectl --anyuser auth can-i --list
@@ -78,7 +78,7 @@ selfsubjectrulesreviews.authorization.k8s.io    []                  []
                                                 [/version]          []               [get]
 ```
 
-In order to enable namespace self-service provisioning, Capsule intentionally gives permissions to create namespaces to all users belonging to the Capsule group:
+To enable namespace self-service provisioning, Capsule intentionally gives permissions to create namespaces to all users belonging to the Capsule group:
 
 ```bash
 kubectl describe clusterrolebindings capsule-namespace-provisioner

docs/operator/mtb/block-access-to-multitenant-resources.md

@@ -6,9 +6,9 @@
 
 **Category:** Tenant Isolation
 
-**Description:** Each tenant namespace may contain resources setup by the cluster administrator for multi-tenancy, such as role bindings, and network policies. Tenants should not be allowed to modify the namespaced resources created by the cluster administrator for multi-tenancy. However, for some resources such as network policies, tenants can configure additional instances of the resource for their workloads.
+**Description:** Each tenant namespace may contain resources set up by the cluster administrator for multi-tenancy, such as role bindings, and network policies. Tenants should not be allowed to modify the namespaced resources created by the cluster administrator for multi-tenancy. However, for some resources such as network policies, tenants can configure additional instances of the resource for their workloads.
 
-**Rationale:** Tenants can escalate priviliges and impact other tenants if they are able to delete or modify required multi-tenancy resources such as namespace resource quotas or default network policy.
+**Rationale:** Tenants can escalate privileges and impact other tenants if they can delete or modify required multi-tenancy resources such as namespace resource quotas or default network policy.
 
 **Audit:**
 
@@ -99,7 +99,7 @@ spec:
 EOF
 ```
 
-However, due the additive nature of networkpolicies, the `DENY ALL` policy set by the cluster admin, prevents the hijacking.
+However, due to the additive nature of networkpolicies, the `DENY ALL` policy set by the cluster admin, prevents hijacking.
 
 As tenant owner list RBAC permissions set by Capsule
 
@@ -110,13 +110,13 @@ namespace-deleter   ClusterRole/capsule-namespace-deleter   11h
 namespace:admin     ClusterRole/admin                       11h
 ```
 
-As tenant owner, try to change/delete  the rolebindings in order to escalate permissions
+As tenant owner, try to change/delete  the rolebinding to escalate permissions
 
 ```bash 
 kubectl --kubeconfig alice edit/delete rolebinding namespace:admin
 ```
 
-The rolebindings is immediately recreated by Capsule:
+The rolebinding is immediately recreated by Capsule:
 
 ```
 kubectl --kubeconfig alice get rolebindings
@@ -125,7 +125,7 @@ namespace-deleter   ClusterRole/capsule-namespace-deleter   11h
 namespace:admin     ClusterRole/admin                       2s
 ```
 
-However, the tenant owner can create and assign permissions inside namespace she owns
+However, the tenant owner can create and assign permissions inside the namespace she owns
 
 ```yaml
 kubectl create -f - << EOF

docs/operator/mtb/block-access-to-other-tenant-resources.md

@@ -6,7 +6,7 @@
 
 **Category:** Tenant Isolation
 
-**Description:** Each tenant has its own set of resources, such as namespaces, service accounts, secrets, pods, services, etc. Tenants should not be allowed to access eachother's resources.
+**Description:** Each tenant has its own set of resources, such as namespaces, service accounts, secrets, pods, services, etc. Tenants should not be allowed to access each other's resources.
 
 **Rationale:** Tenant's resources must be not accessible by other tenants.
 
@@ -69,10 +69,10 @@ As `oil` tenant owner, try to retrieve the resources in the `gas` tenant namespa
 kubectl --kubeconfig alice get serviceaccounts --namespace  gas-production 
 ```
 
-You must receive an eror message:
+You must receive an error message:
 
 ```
-Error from server (Forbidden): serviceaccounts is forbidden:
+Error from server (Forbidden): serviceaccount is forbidden:
 User "oil" cannot list resource "serviceaccounts" in API group "" in the namespace "gas-production"
 ```
 
@@ -82,10 +82,10 @@ As `gas` tenant owner, try to retrieve the resources in the `oil` tenant namespa
 kubectl --kubeconfig joe get serviceaccounts --namespace  oil-production 
 ```
 
-You must receive an eror message:
+You must receive an error message:
 
 ```
-Error from server (Forbidden): serviceaccounts is forbidden:
+Error from server (Forbidden): serviceaccount is forbidden:
 User "joe" cannot list resource "serviceaccounts" in API group "" in the namespace "oil-production"
 ```
 

docs/operator/mtb/block-privilege-escalation.md

@@ -8,7 +8,7 @@
 
 **Description:** Control container permissions.
 
-**Rationale:** The security `allowPrivilegeEscalation` setting allows a process to gain more privileges from its parent process. Processes in tenant containers should not be allowed to gain additional priviliges.
+**Rationale:** The security `allowPrivilegeEscalation` setting allows a process to gain more privileges from its parent process. Processes in tenant containers should not be allowed to gain additional privileges.
 
 **Audit:**
 

docs/operator/mtb/block-use-of-existing-persistent-volumes.md

@@ -8,7 +8,7 @@
 
 **Description:** Avoid a tenant to mount existing volumes`.
 
-**Rationale:** Tenants have to be assured that their Persisten Volumes cannot be reclaimed by other tenants.
+**Rationale:** Tenants have to be assured that their Persistent Volumes cannot be reclaimed by other tenants.
 
 **Audit:**
 

docs/operator/mtb/block-use-of-host-path-volumes.md

@@ -8,7 +8,7 @@
 
 **Description:** Tenants should not be able to mount host volumes and directories.
 
-**Rationale:** The use of host volumes and directories can be used to access shared data or escalate priviliges and also creates a tight coupling between a tenant workload and a host.
+**Rationale:** The use of host volumes and directories can be used to access shared data or escalate privileges and also creates a tight coupling between a tenant workload and a host.
 
 **Audit:**
 

docs/operator/mtb/require-reclaim-policy-of-delete.md

@@ -8,7 +8,7 @@
 
 **Description:** Force a tenant to use a Storage Class with `reclaimPolicy=Delete`.
 
-**Rationale:** Tenants have to be assured that their Persisten Volumes cannot be reclaimed by other tenants.
+**Rationale:** Tenants have to be assured that their Persistent Volumes cannot be reclaimed by other tenants.
 
 **Audit:**
 

docs/operator/mtb/require-run-as-non-root-user.md

@@ -8,7 +8,7 @@
 
 **Description:** Control container permissions.
 
-**Rationale:** Processes in containers run as the root user (uid 0), by default. To prevent potential compromise of container hosts, specify a least privileged user ID when building the container image and require that application containers run as non root users.
+**Rationale:** Processes in containers run as the root user (uid 0), by default. To prevent potential compromise of container hosts, specify a least-privileged user ID when building the container image and require that application containers run as non-root users.
 
 **Audit:**