fix: install npm dependencies

.github/workflows/hugo.yaml

@@ -49,7 +49,7 @@ jobs:
         id: pages
         uses: actions/configure-pages@v4
       - name: Install Node.js dependencies
-        run: "[[ -f package-lock.json || -f npm-shrinkwrap.json ]] && npm ci || true"
+        run: " npm install --save-dev autoprefixer postcss-cli && npm ci || true"
       - name: Build with Hugo
         env:
           # For maximum backward compatibility with Hugo modules

config/_default/hugo.toml

@@ -8,6 +8,8 @@ defaultContentLanguageInSubdir = false
 # Useful when translating.
 enableMissingTranslationPlaceholders = true
 
+editCurrentVersion = false
+
 enableRobotsTXT = true
 
 # Will give values to .Lastmod etc.

content/en/_index.md

@@ -38,7 +38,7 @@ Leverage Kubernetes Admission Controllers to enforce the industry security best
 {{% /blocks/feature %}}
 
 {{% blocks/feature icon="fa-house" title="Native Experience" %}}
-Provide multi-tenancy with a native Kubernetes experience without introducing additional management layers, plugins, or customized binaries.
+Provide multi-tenancy with a native Kubernetes experience without introducing additional management layers, plugins, or customized binaries. Tenancy can be partially present in the cluster.
 {{% /blocks/feature %}}
 
 {{% blocks/feature icon="fa-ghost" title="GitOps" %}}
@@ -52,12 +52,12 @@ Capsule is completely declarative and GitOps ready.
 
 ## Capsule is a CNCF Incubating Project { class="text-center mb-4" }
 
+---
+
 <a href="https://www.cncf.io" target="blank">
-	<img class="cncf-logo img-fluid" src="/images/logo/cncf.svg" alt="Cloud Native Computing Foundation logo">
+	<img class="cncf-logo img-fluid" src="/images/icons/cncf.png" alt="Cloud Native Computing Foundation logo">
 </a>
 
-<br/>
-<br/>
 <br/>
 <br/>
 

content/en/docs/overview/_index.md

@@ -1,6 +1,7 @@
 ---
 title: Overview
 weight: 1
+description: Understand the problem Capsule is attempting to solve and how it works
 ---
 
 Capsule implements a multi-tenant and policy-based environment in your Kubernetes cluster. It is designed as a micro-services-based ecosystem with the minimalist approach, leveraging only on upstream Kubernetes.
@@ -15,4 +16,6 @@ Capsule takes a different approach. In a single cluster, the Capsule Controller
 
 On the other side, the Capsule Policy Engine keeps the different tenants isolated from each other. Network and Security Policies, Resource Quota, Limit Ranges, RBAC, and other policies defined at the tenant level are automatically inherited by all the namespaces in the tenant. Then users are free to operate their tenants in autonomy, without the intervention of the cluster administrator.
 
+<br>
 
+![capsule-operator](/images/content/capsule-operator.svg)

content/en/docs/tutorial/_index.md

@@ -0,0 +1,16 @@
+---
+title: Tutorial
+weight: 4
+description: >
+  Understand principles and concepts of Capsule Tenants
+---
+Capsule is a framework to implement multi-tenant and policy-driven scenarios in Kubernetes. In this tutorial, we'll focus on a hypothetical case covering the main features of the Capsule Operator.
+
+**Acme Corp**, our sample organization, is building a Container as a Service platform (CaaS) to serve multiple lines of business, or departments, e.g. Oil, Gas, Solar, Wind, Water. Each department has its team of engineers that are responsible for the development, deployment, and operating of their digital products. We'll work with the following actors:
+
+* **Bill**: the cluster administrator from the operations department of Acme Corp.
+* **Alice**: the project leader in the Solar & Green departments. She is responsible for a team made of different job responsibilities: e.g. developers, administrators, SRE engineers, etc.
+* **Joe**: works as a lead developer of a distributed team in Alice's organization.
+* **Bob**: is the head of engineering for the Water department, the main and historical line of business at Acme Corp.
+
+This scenario will guide you through the following topics.

content/en/docs/tutorial/configuration.md

@@ -0,0 +1,6 @@
+---
+title: Configuration
+weight: 20
+description: >
+  Understand the Capsule configuration options and how to use them.
+---

content/en/docs/tutorial/permissions.md

@@ -0,0 +1,187 @@
+---
+title: Permissions
+weight: 1
+description: >
+  Grant permissions for tenants
+---
+
+## Ownership
+
+Capsule introduces the principal, that tenants must have owners. The owner of a tenant is a user or a group of users that have the right to create, delete, and manage the tenant's namespaces and other tenant resources. However an owner does not have the permissions to manage the tenants they are owner of. This is still done by cluster-administrators.
+
+### Group Scope
+
+Capsule selects users, which are eligable to be considered for tenancy by their group.
+
+
+
+
+### Assigning Ownership to Users
+
+**Bill**, the cluster admin, receives a new request from Acme Corp's CTO asking for a new tenant to be onboarded and Alice user will be the tenant owner. Bill then assigns Alice's identity of alice in the Acme Corp. identity management system. Since Alice is a tenant owner, Bill needs to assign alice the Capsule group defined by --capsule-user-group option, which defaults to capsule.clastix.io.
+
+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=capsule.clastix.io"`.
+
+**Bill** creates a new tenant oil in the CaaS management portal according to the tenant's profile:
+
+```yaml
+kubectl create -f - << EOF
+apiVersion: capsule.clastix.io/v1beta2
+kind: Tenant
+metadata:
+  name: solar
+spec:
+  owners:
+  - name: alice
+    kind: User
+EOF
+```
+
+**Bill** checks if the new tenant is created and operational:
+
+```bash
+kubectl get tenant solar
+NAME   STATE    NAMESPACE QUOTA   NAMESPACE COUNT   NODE SELECTOR   AGE
+solar    Active                     0                                 33m
+```
+
+> Note that namespaces are not yet assigned to the new tenant. The tenant owners are free to create their namespaces in a self-service fashion and without any intervention from Bill.
+
+Once the new tenant solar is in place, Bill sends the login credentials to Alice. Alice can log in using her credentials and check if she can create a namespace
+
+```bash
+kubectl auth can-i create namespaces
+yes
+```
+
+or even delete the namespace
+
+```bash
+kubectl auth can-i delete ns -n solar-production
+yes
+```
+
+However, cluster resources are not accessible to Alice
+
+```bash
+kubectl auth can-i get namespaces
+no
+
+kubectl auth can-i get nodes
+no
+
+kubectl auth can-i get persistentvolumes
+no
+```
+
+including the Tenant resources
+
+
+```
+kubectl auth can-i get tenants
+no
+```
+
+
+### Group of subjects as tenant owner
+
+In the example above, Bill assigned the ownership of solar tenant to alice user. If another user, e.g. Bob needs to administer the solar tenant, Bill can assign the ownership of solar tenant to such user too:
+
+```bash
+kubectl apply -f - << EOF
+apiVersion: capsule.clastix.io/v1beta2
+kind: Tenant
+metadata:
+  name: solar
+spec:
+  owners:
+  - name: alice
+    kind: User
+  - name: bob
+    kind: User
+EOF
+```
+
+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.
+
+```bash
+kubectl apply -f - << EOF
+apiVersion: capsule.clastix.io/v1beta2
+kind: Tenant
+metadata:
+  name: solar
+spec:
+  owners:
+  - name: solar-users
+    kind: Group
+EOF
+```
+
+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
+
+```bash
+kubectl auth can-i create namespaces
+yes
+```
+
+#### Group of 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:
+
+```bash
+
+```
+
+
+## Rolebindings
+
+With tenant rolebindings you can distribute namespaced rolebindings to all namespaces which are assigned to a namespace. Essentially it is then ensured the defined rolebindings are present and reconciled in all namespaces of the tenant. This is useful if users should have more insights on tenant basis. Let's look at an example.
+
+Assuming a cluster-administrator creates the following clusterRole:
+
+```yaml
+kubectl apply -f - << EOF
+kind: ClusterRole
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+  name: prometheus-servicemonitors-viewer
+rules:
+- apiGroups: ["monitoring.coreos.com"]
+  resources: ["servicemonitors"]
+  verbs: ["get", "list", "watch"]
+EOF
+```
+
+Now the cluster-administrator creates wants to bind this clusterRole in each namespace of the solar tenant. He creates a tenantRoleBinding:
+
+```yaml
+kubectl apply -f - << EOF
+apiVersion: capsule.clastix.io/v1beta2
+kind: Tenant
+metadata:
+  name: solar
+spec:
+  owners:
+  - name: alice
+    kind: User
+  additionalRoleBindings:
+  - clusterRoleName: 'prometheus-servicemonitors-viewer'
+    subjects:
+    - apiGroup: rbac.authorization.k8s.io
+      kind: User
+      name: joe
+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. 
+
+
+
+
+
+
+
+
+
+
+