Merge pull request #59 from stakater/to-update-ic

docs/content/sre/tenant-operator/integration-config.md

@@ -1,6 +1,6 @@
 # Integration Config
 
-Integration config is used to configure settings of multi-tenancy for tenant operator.
+IntegrationConfig is used to configure settings of multi-tenancy for Tenant-Operator.
 
 ```yaml
 apiVersion: tenantoperator.stakater.com/v1alpha1
@@ -65,7 +65,7 @@ spec:
       accessorID: <ACCESSOR_ID_TOKEN>
 ```
 
-Following are the different components that can be used to configure multi-tenancy in a cluster via tenant operator.
+Following are the different components that can be used to configure multi-tenancy in a cluster via Tenant Operator.
 
 ## OpenShift
 ``` yaml
@@ -152,15 +152,15 @@ users:
 
 ### Cluster Admin Groups
 
-`clusterAdminGroups:` Contains names of the groups that are allowed to perform CRUD operations on namespaces present on the cluster. Users in the specified group(s) will be able to perform these operations without the tenant-operator getting in their way
+`clusterAdminGroups:` Contains names of the groups that are allowed to perform CRUD operations on namespaces present on the cluster. Users in the specified group(s) will be able to perform these operations without the Tenant Operator getting in their way
 
 ### Privileged Namespaces
 
-`privilegedNamespaces:` Contains the list of `namespaces` ignored by the tenant-operator. The tenant-operator will not manage the `namespaces` in this list. Values in this list are regex patterns. For example, to ignore the `default` namespace, we can specify `^default$`; and to ignore all `namespaces` starting with the `openshift-` prefix, we can specify `^openshift-*`.
+`privilegedNamespaces:` Contains the list of `namespaces` ignored by the Tenant Operator. The Tenant Operator will not manage the `namespaces` in this list. Values in this list are regex patterns. For example, to ignore the `default` namespace, we can specify `^default$`; and to ignore all `namespaces` starting with the `openshift-` prefix, we can specify `^openshift-*`.
 
 ### Privileged ServiceAccounts
 
-`privilegedServiceAccounts:` Contains the list of `ServiceAccounts` ignored by the tenant-operator. The tenant-operator will not manage the `ServiceAccounts` in this list. Values in this list are regex patterns. For example, to ignore all `ServiceAccounts` starting with the `system:serviceaccount:openshift-` prefix, we can use `^system:serviceaccount:openshift-*`; and to ignore the `system:serviceaccount:builder` service account we can use `^system:serviceaccount:builder$.`
+`privilegedServiceAccounts:` Contains the list of `ServiceAccounts` ignored by the Tenant Operator. The Tenant Operator will not manage the `ServiceAccounts` in this list. Values in this list are regex patterns. For example, to ignore all `ServiceAccounts` starting with the `system:serviceaccount:openshift-` prefix, we can use `^system:serviceaccount:openshift-*`; and to ignore the `system:serviceaccount:builder` service account we can use `^system:serviceaccount:builder$.`
 
 ### Namespace Access Policy
 
@@ -184,7 +184,7 @@ If you want to use a more complex regex pattern (for the `openshift.privilegedNa
 
 ### Namespace
 
-`argocd.namespace` is an optional field used to specify the namespace where ArgoCD applications and app projects are deployed. The field should be populated when you want to create an ArgoCD AppProject for each tenant
+`argocd.namespace` is an optional field used to specify the namespace where ArgoCD applications and app projects are deployed. The field should be populated when you want to create an ArgoCD AppProject for each tenant.
 
 ### NamespaceResourceBlacklist
 

docs/content/sre/tenant-operator/usecases/integrationconfig.md

@@ -2,14 +2,16 @@
 
 Bill is a cluster admin who can use `IntegrationConfig` to configure how `Tenant-Operator` manages the cluster.
 
-By default, Tenant-Operator watches all namespaces and will enforce all the governing policies on them.
+By default, Tenant Operator watches all namespaces and will enforce all the governing policies on them. 
+All namespaces managed by Tenant Operator require the `stakater.com/tenant` label. 
+Tenant Operator ignores privileged namespaces that are mentioned in the IntegrationConfig, and does not manage them. These namespaces do not require the above-mentioned label. 
 
 ```bash
 oc create namespace stakater-test
 Error from server (Cannot Create namespace stakater-test without label stakater.com/tenant. User: Bill): admission webhook "vnamespace.kb.io" denied the request: Cannot CREATE namespace stakater-test without label stakater.com/tenant. User: Bill
 ```
 
-If Bill wants to ignore namespaces like `default`, or namespaces with prefixes like `openshift`, `kube`, then Bill would simply add them in integration config like:
+Bill is trying to create a namespace without the `stakater.com/tenant` label. Creating a namespace without this label is only allowed if the namespace is privileged. Privileged namespaces will be ignored by TO and do not require the said label. Therefore, Bill will add the required regex in the IntegrationConfig, along with any other namespaces which are privileged and should be ignored by Tenant Operator - like `default`, or namespaces with prefixes like `openshift`, `kube`:
 
 ```yaml
 apiVersion: tenantoperator.stakater.com/v1alpha1
@@ -20,21 +22,22 @@ metadata:
 spec:
   openshift:
     privilegedNamespaces:
-      - default
+      - ^default$
       - ^openshift*
       - ^kube*
+      - ^stakater*
 ```
 
-After setting `privilegedNamespaces`, Bill can create namespaces without interference.
+After mentioning the required regex (`^stakater*`) under `privilegedNamespaces`, Bill can create the namespace without interference.
 
 ```bash
 oc create namespace stakater-test
 namespace/stakater-test created
 ```
 
-Tenant-Operator will also disallow all users which are not tenant owners to perform CRUD operation on namespaces. This will also prevent Service Accounts from performing CRUD operations.
+Tenant Operator will also disallow all users which are not tenant owners to perform CRUD operations on namespaces. This will also prevent Service Accounts from performing CRUD operations.
 
-If Bill wants Tenant-Operator to ignore Service Accounts, than Bill would simply have to add them in integration config:
+If Bill wants Tenant Operator to ignore Service Accounts, than Bill would simply have to add them in IntegrationConfig:
 
 ```yaml
 apiVersion: tenantoperator.stakater.com/v1alpha1
@@ -69,13 +72,13 @@ spec:
 
 ## Configuring Vault in IntegrationConfig
 
-[Vault](https://www.vaultproject.io/) is used to secure, store and tightly control access to tokens, passwords, certificates, encryption keys for protecting secrets and other sensitive data using a UI, CLI, or HTTP API.
+[Vault](https://www.vaultproject.io/) is used to secure, store and tightly control access to tokens, passwords, certificates, and encryption keys for protecting secrets and other sensitive data using a UI, CLI, or HTTP API.
 
-If Bill the cluster admin has Vault configured in his cluster, than he can take benefit from Tenant-Operators integration with Vault.
+If Bill (the cluster admin) has Vault configured in his cluster, then he can take benefit from Tenant Operator's integration with Vault.
 
-Tenant-Operator automatically creates Vault secret paths for tenants where tenant members can securely save their secrets and also authorizes tenant members to access these secrets via OIDC.
+Tenant Operator automatically creates Vault secret paths for tenants, where tenant members can securely save their secrets. It also authorizes tenant members to access these secrets via OIDC.
 
-Bill would first have to integrate Vault with Tenant-Operator by adding the details in integrationConfig. For more [details](../integration-config.html#vault)
+Bill would first have to integrate Vault with Tenant Operator by adding the details in IntegrationConfig. For more [details](../integration-config.html#vault)
 
 ```yaml
 apiVersion: tenantoperator.stakater.com/v1alpha1
@@ -97,7 +100,7 @@ spec:
       clientName: vault
 ```
 
-Bill then creates a tenant for Anna and John
+Bill then creates a tenant for Anna and John:
 
 ```yaml
 apiVersion: tenantoperator.stakater.com/v1beta2
@@ -123,11 +126,11 @@ Now if Anna sign's in to the Vault via OIDC, she can see her tenants path and se
 
 Red Hat Single Sign-On [RHSSO](https://access.redhat.com/products/red-hat-single-sign-on) is based on the Keycloak project and enables you to secure your web applications by providing Web single sign-on (SSO) capabilities based on popular standards such as SAML 2.0, OpenID Connect and OAuth 2.0.
 
-If Bill the cluster admin has RHSSO configured in his cluster, than he can take benefit from Tenant-Operator's integration with RHSSO and Vault.
+If Bill the cluster admin has RHSSO configured in his cluster, then he can take benefit from Tenant Operator's integration with RHSSO and Vault.
 
-Tenant-Operator automatically allows tenant members to access Vault via OIDC(RHSSO authentication and authorization) to access secret paths for tenants where tenant members can securely save their secrets.
+Tenant Operator automatically allows tenant members to access Vault via OIDC(RHSSO authentication and authorization) to access secret paths for tenants where tenant members can securely save their secrets.
 
-Bill would first have to integrate RHSSO with Tenant-Operator by adding the details in integration config. [Visit here](../integration-config.html#rhsso-red-hat-single-sign-on) for more details.
+Bill would first have to integrate RHSSO with Tenant Operator by adding the details in IntegrationConfig. [Visit here](../integration-config.html#rhsso-red-hat-single-sign-on) for more details.
 
 ```yaml
 rhsso: