Merge pull request #32 from santhakali/fix-tenant-permissions-page-typos

Fix: Typos in the Tenant Permissions page documentation

Author: Svarrogh1337

content/en/docs/resourcepools/_index.md

@@ -292,7 +292,7 @@ spec:
 
 ## ResourcePoolClaims
 
-`ResourcePoolClaims` declared claims of resources from a single `ResourcePool`. When a `ResourcePoolClaim` is successfully bound to a `ResourcePool`, it's requested resources are stacked to the `ResourceQuota` from the `ResourcePool` in the correspinding namespaces, where the `ResourcePoolClaim` was declared. So the declaration of a `ResourcePoolClaim` is very simple:
+`ResourcePoolClaims` declared claims of resources from a single `ResourcePool`. When a `ResourcePoolClaim` is successfully bound to a `ResourcePool`, it's requested resources are stacked to the `ResourceQuota` from the `ResourcePool` in the corresponding namespaces, where the `ResourcePoolClaim` was declared. So the declaration of a `ResourcePoolClaim` is very simple:
 
 ```yaml
 apiVersion: capsule.clastix.io/v1beta2
@@ -308,7 +308,7 @@ spec:
 
 ```
 
-`ResourcePoolClaims` are decoupled from the lifecycle of `ResourcePools`. If a `ResourcePool` is deleted where a `ResourcePoolClaim` was bound to, the `ResourcePoolClaim` becomes unassigned, but is not deleted. 
+`ResourcePoolClaims` are decoupled from the lifecycle of `ResourcePools`. If a `ResourcePool` is deleted where a `ResourcePoolClaim` was bound to, the `ResourcePoolClaim` becomes unassigned, but is not deleted.
 
 ### Allocation
 
@@ -554,7 +554,7 @@ spec:
     limits.memory: 384Mi
 ```
 
-The same can be done for the `capsule-migration-1` `ResourceQuota`. 
+The same can be done for the `capsule-migration-1` `ResourceQuota`.
 
 ```yaml
 ---
@@ -666,7 +666,7 @@ So, there needs to be change. But times have also changed and we have listened t
 
 **Our initial Idea for a redesign was simple**: What if we just intercepted operations on the `resourcequota/status` subresource and calculate the offsets (or essentially what still can fit) on a Admission-Webhook. If another operation would have taken place the client operation would have thrown a conflict and rejected the admission, until it retries. Makes sense, right?
 
-Here we have the problem, that even if we would block resourcequota status updates and wait until the actual quantity was added to the total, the resources have already been scheduled. The reason for that, is that the status for resourcequotas is **eventually** consistent, but what really matters at that moment is the hard spec (see this response from a maintainer [kubernetes/kubernetes#123434 (comment)](https://github.com/kubernetes/kubernetes/issues/123434#issuecomment-1964920277)). So essentially no matter the status, you can always provision as much resources, as the `.spec.hard` of a `ResourceQuota` indicates. This makes perfect sense, if your `ResourceQuota` is acting in a single namespace. However in our scenario, we have the same `ResourceQuota` in n-namespaces. So the overprovisioning problem still persists. 
+Here we have the problem, that even if we would block resourcequota status updates and wait until the actual quantity was added to the total, the resources have already been scheduled. The reason for that, is that the status for resourcequotas is **eventually** consistent, but what really matters at that moment is the hard spec (see this response from a maintainer [kubernetes/kubernetes#123434 (comment)](https://github.com/kubernetes/kubernetes/issues/123434#issuecomment-1964920277)). So essentially no matter the status, you can always provision as much resources, as the `.spec.hard` of a `ResourceQuota` indicates. This makes perfect sense, if your `ResourceQuota` is acting in a single namespace. However in our scenario, we have the same `ResourceQuota` in n-namespaces. So the overprovisioning problem still persists.
 
 
 **Thinking of other ways**: So the next idea was essentially increasing the `ResourceQuota.spec.hard` based on the workloads which are added to a namespaces (essentially a reversed approach). The workflow for this would look like something like this:
@@ -684,7 +684,7 @@ But there's some problems with this approach as well:
   * if you eg. schedule a pod and the quota is `count/0` there's no admission call on the resourcequota, which would be the easiest. So we would need to find a way to know, there's something new requesting resources. For example [Rancher](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces#4-optional-add-resource-quotas) works around this problem with namespaced `DefaultLimits`. But this is not the agile approach we would like to offer.
   * The only indication that I know of is that we get an Event, which we can intercept with admission (`ResourceQuota Denied`), regarding quotaoverprovision.
 
-If you eg update the resource quota that a pod now has space, it takes some time until that's registered and actually scheduled (just tested it for pods). I guess the timing depends on the kube-controller-manager flag `--concurrent-resource-quota-syncs`  and/or `--resource-quota-sync-period 
+If you eg update the resource quota that a pod now has space, it takes some time until that's registered and actually scheduled (just tested it for pods). I guess the timing depends on the kube-controller-manager flag `--concurrent-resource-quota-syncs`  and/or `--resource-quota-sync-period
 
 So it's really really difficult to increase quotas by the resources which are actually requested, especially the adding new resources process is where the performance would take a heavy hit.
 

content/en/docs/tenants/enforcement.md

@@ -18,7 +18,7 @@ The cluster admin can "taint" the namespaces created by tenant owners with addit
 apiVersion: capsule.clastix.io/v1beta2
 kind: Tenant
 metadata:
-  name: oil
+  name: solar
 spec:
   owners:
   - name: alice
@@ -64,7 +64,7 @@ Assigns additional labels and annotations to all namespaces created in the `sola
 apiVersion: capsule.clastix.io/v1beta2
 kind: Tenant
 metadata:
-  name: oil
+  name: solar
 spec:
   owners:
   - name: alice
@@ -123,7 +123,7 @@ spec:
       denied:
           - foo.acme.net
           - bar.acme.net
-      deniedRegex: .*.acme.net 
+      deniedRegex: .*.acme.net
     forbiddenLabels:
       denied:
           - foo.acme.net
@@ -152,7 +152,7 @@ Bill, the cluster admin, can deny Tenant Owners to add or modify specific labels
 apiVersion: capsule.clastix.io/v1beta2
 kind: CapsuleConfiguration
 metadata:
-  name: default 
+  name: default
 spec:
   nodeMetadata:
     forbiddenAnnotations:
@@ -208,8 +208,8 @@ metadata:
 spec:
   ports:
   - protocol: TCP
-    port: 80 
-    targetPort: 8080 
+    port: 80
+    targetPort: 8080
   selector:
     run: nginx
   type: ClusterIP
@@ -416,15 +416,15 @@ To prevent misuses of Pod Priority Class, Bill, the cluster admin, can enforce t
 apiVersion: capsule.clastix.io/v1beta2
 kind: Tenant
 metadata:
-  name: oil
+  name: solar
 spec:
   owners:
   - name: alice
     kind: User
   priorityClasses:
     matchLabels:
       env: "production"
-``` 
+```
 
 With the said Tenant specification, Alice can create a Pod resource if `spec.priorityClassName` equals to:
 
@@ -502,7 +502,7 @@ If a Pod is going to use a non-allowed Runtime Class, it will be rejected by the
 
 ### NodeSelector
 
-Bill, the cluster admin, can dedicate a pool of worker nodes to the oil tenant, to isolate the tenant applications from other noisy neighbors.
+Bill, the cluster admin, can dedicate a pool of worker nodes to the solar tenant, to isolate the tenant applications from other noisy neighbors.
 
 These nodes are labeled by Bill as `pool=renewable`
 
@@ -557,7 +557,7 @@ spec:
 ```
 
 Any attempt of Alice to change the selector on the pods will result in an error from the PodNodeSelector Admission Controller plugin.
-    
+
 ```bash
 kubectl auth can-i edit ns -n solar-production
 no
@@ -911,7 +911,7 @@ metadata:
 spec:
   ingressClassName: legacy
   rules:
-  - host: oil.acmecorp.com
+  - host: solar.acmecorp.com
     http:
       paths:
       - backend:
@@ -980,7 +980,7 @@ Kubernetes network policies control network traffic between namespaces and betwe
 To meet this requirement, Bill needs to define network policies that deny pods belonging to Alice's namespaces to access pods in namespaces belonging to other tenants, e.g. Bob's tenant `water`, or in system namespaces, e.g. `kube-system`.
 
 > Keep in mind, that because of how the NetworkPolicies API works, the users can still add a policy which contradicts what the Tenant has set, resulting in users being able to circumvent the initial limitation set by the tenant admin. Two options can be put in place to mitigate this potential privilege escalation: 1. providing a restricted role rather than the default admin one 2. using Calico's GlobalNetworkPolicy, or Cilium's CiliumClusterwideNetworkPolicy which are defined at the cluster-level, thus creating an order of packet filtering.
-    
+
 Also, Bill can make sure pods belonging to a tenant namespace cannot access other network infrastructures like cluster nodes, load balancers, and virtual machines running other services.
 
 Bill can set network policies in the tenant manifest, according to the requirements:
@@ -1004,12 +1004,12 @@ spec:
         - ipBlock:
             cidr: 0.0.0.0/0
             except:
-              - 192.168.0.0/16 
+              - 192.168.0.0/16
       ingress:
       - from:
         - namespaceSelector:
             matchLabels:
-              capsule.clastix.io/tenant: oil
+              capsule.clastix.io/tenant: water
         - podSelector: {}
         - ipBlock:
             cidr: 192.168.0.0/16
@@ -1202,7 +1202,7 @@ With the said Tenant specification, Alice can create a Persistent Volume Claims
 
 Capsule assures that all Persistent Volume Claims created by Alice will use only one of the valid storage classes. Assume the StorageClass `ceph-rbd` has the label `env: production`:
 
-```bash 
+```bash
 kubectl apply -f - << EOF
 kind: PersistentVolumeClaim
 apiVersion: v1
@@ -1233,7 +1233,7 @@ It's possible to assign each tenant a StorageClass which will be used, if no val
 apiVersion: capsule.clastix.io/v1beta2
 kind: Tenant
 metadata:
-  name: oil
+  name: solar
 spec:
   owners:
   - name: alice
@@ -1416,4 +1416,4 @@ spec:
   - name: alice
     kind: User
   preventDeletion: true
-```
+```

content/en/docs/tenants/permissions.md

@@ -11,7 +11,7 @@ Capsule introduces the principal, that tenants must have owners. The owner of a
 
 ### Group Scope
 
-Capsule selects users, which are eligable to be considered for tenancy by their group. The define the group of users that can be considered for tenancy, you can use the `userGroups` option in the CapsuleConfiguration. 
+Capsule selects users, which are eligable to be considered for tenancy by their group. To define the group of users that can be considered for tenancy, you can use the `userGroups` option in the CapsuleConfiguration.
 
 Another commonly used example if you want to promote serviceaccount to tenant-owners, their group must be present:
 
@@ -38,7 +38,7 @@ Learn how to assign ownership to users, groups and serviceaccounts.
 
 To keep things simple, we assume that Bill just creates a client certificate for authentication using X.509 Certificate Signing Request, so Alice's certificate has `"/CN=alice/O=projectcapsule.dev"`.
 
-**Bill** creates a new tenant oil in the CaaS management portal according to the tenant's profile:
+**Bill** creates a new tenant solar in the CaaS management portal according to the tenant's profile:
 
 ```yaml
 apiVersion: capsule.clastix.io/v1beta2
@@ -113,7 +113,7 @@ spec:
     kind: User
 ```
 
-However, it's more likely that Bill assigns the ownership of the solar tenant to a group of users instead of a single one, especially if you use [OIDC AUthentication](/docs/guides/authentication#oidc). Bill creates a new group account solar-users in the Acme Corp. identity management system and then he assigns Alice and Bob identities to the solar-users group.
+However, it's more likely that Bill assigns the ownership of the solar tenant to a group of users instead of a single one, especially if you use [OIDC Authentication](/docs/guides/authentication#oidc). Bill creates a new group account solar-users in the Acme Corp. identity management system and then he assigns Alice and Bob identities to the solar-users group.
 
 ```yaml
 apiVersion: capsule.clastix.io/v1beta2
@@ -126,7 +126,7 @@ spec:
     kind: Group
 ```
 
-With the configuration above, any user belonging to the `solar-users` group will be the owner of the oil tenant with the same permissions of Alice. For example, Bob can log in with his credentials and issue
+With the configuration above, any user belonging to the `solar-users` group will be the owner of the solar tenant with the same permissions of Alice. For example, Bob can log in with his credentials and issue
 
 ```bash
 kubectl auth can-i create namespaces
@@ -137,7 +137,7 @@ All the groups you want to promot to Tenant Owners must be part of the Group Sco
 
 #### ServiceAccounts
 
-You can use the Group subject to grant serviceaccounts the ownership of a tenant. For example, you can create a group of serviceaccounts and assign it to the tenant:
+You can use the Group subject to grant ServiceAccounts the ownership of a tenant. For example, you can create a group of ServiceAccounts and assign it to the tenant:
 
 ```yaml
 apiVersion: capsule.clastix.io/v1beta2
@@ -150,7 +150,7 @@ spec:
     kind: ServiceAccount
 ```
 
-Bill can create a Service Account called robot, for example, in the `tenant-system` namespace and leave it to act as Tenant Owner of the oil tenant
+Bill can create a ServiceAccount called robot, for example, in the `tenant-system` namespace and leave it to act as Tenant Owner of the solar tenant
 
 ```bash
 kubectl --as system:serviceaccount:tenant-system:robot --as-group projectcapsule.dev auth can-i create namespaces
@@ -274,7 +274,7 @@ items:
 kind: List
 metadata:
   resourceVersion: ""
-``` 
+```
 
 In some cases, the cluster admin needs to narrow the range of permissions assigned to tenant owners by assigning a Cluster Role with less permissions than above. Capsule supports the dynamic assignment of any ClusterRole resources for each Tenant Owner.
 
@@ -438,7 +438,7 @@ spec:
 EOF
 ```
 
-As you can see the subjects is a classic [rolebinding subject](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#referring-to-subjects). This way you grant permissions to the subject user **Joe**, who only can list and watch servicemonitors in the solar tenant namespaces, but has no other permissions. 
+As you can see the subjects is a classic [rolebinding subject](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#referring-to-subjects). This way you grant permissions to the subject user **Joe**, who only can list and watch servicemonitors in the solar tenant namespaces, but has no other permissions.
 
 ### Custom Resources
 

content/en/docs/tenants/quotas.md

@@ -13,7 +13,7 @@ With help of Capsule, Bill, the cluster admin, can set and enforce resources quo
 This feature will be deprecated in a future release of Capsule. Instead use [Resource Pools](/docs/resourcepools/) to handle any cases around distributed ResourceQuotas
 {{% /alert %}}
 
-With help of Capsule, Bill, the cluster admin, can set and enforce resources quota and limits for Alice's tenant.Set resources quota for each namespace in the Alice's tenant by defining them in the tenant spec:
+With help of Capsule, Bill, the cluster admin, can set and enforce resources quota and limits for Alice's tenant. Set resources quota for each namespace in the Alice's tenant by defining them in the tenant spec:
 
 ```yaml
 apiVersion: capsule.clastix.io/v1beta2
@@ -120,7 +120,7 @@ spec:
 
 ### Tenant Scope
 
-By setting enforcement at tenant level, i.e. `spec.resourceQuotas`.scope=Tenant, Capsule aggregates resources usage for all namespaces in the tenant and adjusts all the `ResourceQuota` usage as aggregate. In such case, Alice can check the used resources at the tenant level by inspecting the annotations in ResourceQuota object of any namespace in the tenant:
+By setting enforcement at tenant level, i.e. `spec.resourceQuotas.scope=Tenant`, Capsule aggregates resources usage for all namespaces in the tenant and adjusts all the `ResourceQuota` usage as aggregate. In such case, Alice can check the used resources at the tenant level by inspecting the annotations in ResourceQuota object of any namespace in the tenant:
 
 ```bash
 kubectl -n solar-production get resourcequotas capsule-solar-1 -o yaml
@@ -263,7 +263,7 @@ spec:
 
 The Additional Role Binding referring to the Cluster Role mysql-namespace-admin is required to let Alice [manage their Custom Resource instances](/docs/tenants/permissions/#custom-resources).
 
-The pattern for the quota.resources.capsule.clastix.io annotation is the following: 
+The pattern for the quota.resources.capsule.clastix.io annotation is the following:
 
 * `quota.resources.capsule.clastix.io/${PLURAL_NAME}.${API_GROUP}_${API_VERSION}`