diff --git a/SELF_ASSESSMENT.md b/SELF_ASSESSMENT.md index 564b57fb..2a0f9b63 100644 --- a/SELF_ASSESSMENT.md +++ b/SELF_ASSESSMENT.md @@ -59,7 +59,7 @@ ## Overview -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. +Capsule implements a multi-tenant and policy-based environment in your Kubernetes cluster. It is designed as a micro-services-based ecosystem with a minimalist approach, leveraging only on upstream Kubernetes. ### Background @@ -75,19 +75,19 @@ Capsule was accepted as a CNCF sandbox project in December 2022. It's the Operator which provides all the multi-tenant capabilities offered by Capsule. It's made of two internal components, such as the webhooks server (known as _policy engine_), and the _manager_. -The manager is responsible of reconciling the required objects at the Namespace level, such as _Network Policy_, _LimitRange_, _ResourceQuota_, _Role Binding_, as well as labelling the Namespace objects belonging to a Tenant according to their desired metadata. +The manager is responsible for reconciling the required objects at the Namespace level, such as _Network Policy_, _LimitRange_, _ResourceQuota_, _Role Binding_, as well as labelling the Namespace objects belonging to a Tenant according to their desired metadata. -Furthermore, the manager is able to replicate objects thanks to the **Tenant Resource** API, which is offering two level of interactions: a cluster scoped one thanks to the `GlobalTenantResource` API, and a namespace scoped one named `TenantResource`. +Furthermore, the manager can replicate objects thanks to the **Tenant Resource** API, which offers two levels of interactions: a cluster-scoped one thanks to the `GlobalTenantResource` API, and a namespace-scoped one named `TenantResource`. The replicated resources are dynamically created, and replicated by Capsule itself, as well as preserving the deletion of these objects by the Tenant owner. -The webhook server, also known as policy engine, is interpolating the Tenant rules an takes full advantage of the dynamic admission controllers offered by Kubernetes itself (such as `ValidatingWebhookConfiguration` an `MutatingWebhookConfiguration`). Thanks to the _policy engine_ the cluster administrators can enforce specific rules such as preventing _Pod_ objects from untrusted registries to run, or preventing the creation of _PersistentVolumeClaim_ resources using a non allowed _StorageClass_, etc. +The webhook server, also known as the policy engine, interpolates the Tenant rules and takes full advantage of the dynamic admission controllers offered by Kubernetes itself (such as `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration`). Thanks to the _policy engine_ the cluster administrators can enforce specific rules such as preventing _Pod_ objects from untrusted registries to run or preventing the creation of _PersistentVolumeClaim_ resources using a non-allowed _StorageClass_, etc. ### Capsule Proxy The `capsule-proxy` is an addon which is offering a Kubernetes API Server shim aware of the multi-tenancy levels implemented by Capsule. -It's essentially a reverse proxy which is decorating the incoming requests with the required `labelSelector` query string parameters to filter out some objects, such as: +It's essentially a reverse proxy that decorates the incoming requests with the required `labelSelector` query string parameters to filter out some objects, such as: - Namespaces - IngressClass @@ -96,9 +96,9 @@ It's essentially a reverse proxy which is decorating the incoming requests with - RuntimeClass - PersistentVolumes -Permissions on those resources is not enforced through the classic Kubernetes RBAC but rather at the Tenant Owner level, allowing a fine-grained control over specific resources. +Permissions on those resources are not enforced through the classic Kubernetes RBAC but rather at the Tenant Owner level, allowing fine-grained control over specific resources. -`capsule-proxy` is not serving itself Kubernetes API server responses, but rather, it's acting as middle proxy server offering a dynamic filtering of requests: this means the resulting responses from the upstream are not mangled, and doesn't require any additional plugins, or third-party binaries, and integrating with any external components, such as the Kubernetes dashboard, the `kubectl` binary, etc. +`capsule-proxy` is not serving itself Kubernetes API server responses, but rather, it's acting as a middle proxy server offering dynamic filtering of requests: this means the resulting responses from the upstream are not mangled, and don't require any additional plugins, or third-party binaries, and integrating with any external components, such as the Kubernetes dashboard, the `kubectl` binary, etc. The capsule-proxy is managed in this [repository](https://github.com/projectcapsule/capsule). @@ -106,14 +106,14 @@ The capsule-proxy is managed in this [repository](https://github.com/projectcaps ### Creating a Tenant -Tenants are created by cluster administrators, who have the write to create Tenant CRs. Tenants should not be managed by end users. Therefor it's not possible for users without any cluster administration rights to list tenants or create tenants. +Tenants are created by cluster administrators, who have the right to create Tenant CRs. End users should not manage tenants. Therefore users without any cluster administration rights can't list tenants or create tenants. ## Creating namespaces in a tenant -When creating a tenant, the capsule controller inspects the user's supplied groups and matches, if the groups were defined in the `capsuleConfiguration`. If atleast one matching group is found, the user request is considered by Capsule. If not, Capsule ignores the request and does not perform any action. This also applies for modifications (UPDATE request). +When creating a tenant, the capsule controller inspects the user's supplied groups and matches, if the groups were defined in the `capsuleConfiguration`. If atleast one matching group is found, the user request is considered by Capsule. If not, Capsule ignores the request and does not perform any action. This also applies to modifications (UPDATE request). To create namespaces within a tenant a User, Group or ServiceAccount must be configured as owner of the tenant. -A namespace is assigned to tenant based on it's label, it's owner (if the owner only has one tenant) or the prefix of the namespace (which matches the tenant name). +A namespace is assigned to a tenant based on its label, its owner (if the owner only has one tenant) or the prefix of the namespace (which matches the tenant name). If the request is considered, the namespace is created with all the configuration on the tenant, which is relevant. The additional resources (networkpolicies, quotas, limitranges) are created in the new namespace. @@ -151,13 +151,10 @@ This document provides the CNCF TAG-Security with an initial understanding of Ca See [Actors](#actors) and [Actions](#actions) for more detailed description of the critical actors, actions, and potential threats. - - ## Project compliance As of now, not applicable. - ## Secure development practices The Capsule project follows established CNCF and OSS best practices for code development and delivery. Capsule follows [OpenSSF Best Practices](https://www.bestpractices.dev/en/projects/5601). Although not perfect yet, we are constantly trying to improve and score optimal scores. We will assess the issues during our community meetings and try to plan them for future releases.