docs: add few test cases

This commit is contained in:
bsctl
2021-08-11 09:38:41 +02:00
committed by Dario Tranchitella
parent e4e3283b90
commit 894ea5016b
4 changed files with 328 additions and 0 deletions
@@ -0,0 +1,48 @@
# Block access to cluster resources
**Profile Applicability:** L1
**Type:** Configuration Check
**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.
**Rationale:** Access controls should be configured for tenants so that a tenant cannot list, create, modify or delete cluster resources
**Audit:**
As cluster admin, create a tenant
```yaml
kubectl create -f - <<EOF
apiVersion: capsule.clastix.io/v1beta1
kind: Tenant
metadata:
name: oil
spec:
owners:
- kind: User
name: alice
EOF
./create-user.sh alice oil
```
As cluster admin, run the following command to retrieve the list of non-namespaced resources
```bash
kubectl --kubeconfig cluster-admin api-resources --namespaced=false
```
For all non-namespaced resources, and each verb (get, list, create, update, patch, watch, delete, and deletecollection) issue the following command:
```bash
kubectl --kubeconfig alice auth can-i <verb> <resource>
```
Each command must return `no`
**Cleanup:**
As cluster admin, delete all the created resources
```bash
kubectl --kubeconfig cluster-admin delete tenant oil
```
@@ -0,0 +1,153 @@
# Block access to multitenant resources
**Profile Applicability:** L1
**Type:** Behavioral
**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.
**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.
**Audit:**
As cluster admin, create a tenant
```yaml
kubectl create -f - <<EOF
apiVersion: capsule.clastix.io/v1beta1
kind: Tenant
metadata:
name: oil
spec:
owners:
- kind: User
name: alice
networkPolicies:
items:
- podSelector: {}
policyTypes:
- Ingress
- Egress
- egress:
- to:
- namespaceSelector:
matchLabels:
capsule.clastix.io/tenant: oil
ingress:
- from:
- namespaceSelector:
matchLabels:
capsule.clastix.io/tenant: oil
podSelector: {}
policyTypes:
- Egress
- Ingress
EOF
./create-user.sh alice oil
```
As tenant owner, run the following command to create a namespace in the given tenant
```bash
kubectl --kubeconfig alice create ns oil-production
kubectl --kubeconfig alice config set-context --current --namespace oil-production
```
As tenant owner, retrieve the networkpolicies resources in the tenant namespace
```bash
kubectl --kubeconfig alice get networkpolicies
NAME POD-SELECTOR AGE
capsule-oil-0 <none> 7m5s
capsule-oil-1 <none> 7m5s
```
As tenant owner try to modify or delete one of the networkpolicies
```bash
kubectl --kubeconfig alice delete networkpolicies capsule-oil-0
```
You should receive an error message denying the edit/delete request
```bash
Error from server (Forbidden): networkpolicies.networking.k8s.io "capsule-oil-0" is forbidden: User "oil" cannot delete resource "networkpolicies" in API group "networking.k8s.io" in the namespace "oil-production"
```
As tenant owner, you can create an additional networkpolicy inside the namespace
```yaml
kubectl create -f - << EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: hijacking
namespace: oil-production
spec:
egress:
- to:
- ipBlock:
cidr: 0.0.0.0/0
podSelector: {}
policyTypes:
- Egress
EOF
```
However, due the additive nature of networkpolicies, the `DENY ALL` policy set by the cluster admin, prevents the hijacking.
As tenant owner list RBAC permissions set by Capsule
```bash
kubectl --kubeconfig alice get rolebindings
NAME ROLE AGE
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
```bash
kubectl --kubeconfig alice edit/delete rolebinding namespace:admin
```
You should receive an error message:
```
error: rolebindings.rbac.authorization.k8s.io "namespace:admin" could not be patched:
rolebindings.rbac.authorization.k8s.io "namespace:admin" is forbidden:
...
```
However, the tenant owner can create and assign permissions inside namespace she owns
```yaml
kubectl create -f - << EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
labels:
name: oil-robot:admin
namespace: oil-production
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: admin
subjects:
- kind: ServiceAccount
name: default
namespace: oil-production
EOF
```
**Cleanup:**
As cluster admin, delete all the created resources
```bash
kubectl --kubeconfig cluster-admin delete tenant oil
```
@@ -0,0 +1,97 @@
# Block access to other tenant resources
**Profile Applicability:** L1
**Type:** Behavioral
**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.
**Rationale:** Tenant's resources must be not accessible by other tenants.
**Audit:**
As cluster admin, create a couple of tenants
```yaml
kubectl create -f - <<EOF
apiVersion: capsule.clastix.io/v1beta1
kind: Tenant
metadata:
name: oil
spec:
owners:
- kind: User
name: alice
EOF
./create-user.sh alice oil
```
and
```yaml
kubectl create -f - <<EOF
apiVersion: capsule.clastix.io/v1beta1
kind: Tenant
metadata:
name: gas
spec:
owners:
- kind: User
name: joe
EOF
./create-user.sh joe gas
```
As `oil` tenant owner, run the following command to create a namespace in the given tenant
```bash
kubectl --kubeconfig alice create ns oil-production
kubectl --kubeconfig alice config set-context --current --namespace oil-production
```
As `gas` tenant owner, run the following command to create a namespace in the given tenant
```bash
kubectl --kubeconfig joe create ns gas-production
kubectl --kubeconfig joe config set-context --current --namespace gas-production
```
As `oil` tenant owner, try to retrieve the resources in the `gas` tenant namespaces
```bash
kubectl --kubeconfig alice get serviceaccounts --namespace gas-production
```
You should receive an eror message:
```
Error from server (Forbidden): serviceaccounts is forbidden:
User "oil" cannot list resource "serviceaccounts" in API group "" in the namespace "gas-production"
```
As `gas` tenant owner, try to retrieve the resources in the `oil` tenant namespaces
```bash
kubectl --kubeconfig joe get serviceaccounts --namespace oil-production
```
You should receive an eror message:
```
Error from server (Forbidden): serviceaccounts is forbidden:
User "joe" cannot list resource "serviceaccounts" in API group "" in the namespace "oil-production"
```
**Cleanup:**
As cluster admin, delete all the created resources
```bash
kubectl --kubeconfig cluster-admin delete tenants oil gas
```
@@ -0,0 +1,30 @@
# Meet the multi-tenancy benchmark MTB
Actually, there's no yet a real standard for the multi-tenancy model in Kubernetes, although the [SIG multi-tenancy group](https://github.com/kubernetes-sigs/multi-tenancy) is working on that. SIG multi-tenancy drafted a generic validation schema appliable to generic multi-tenancy projects. Multi-Tenancy Benchmarks [MTB](https://github.com/kubernetes-sigs/multi-tenancy/tree/master/benchmarks) are guidelines for multi-tenant configuration of Kubernetes clusters. Capsule is an open source multi-tenacy operator and we decided to meet the requirements of MTB.
> N.B. At time of writing, the MTB are in development and not ready for usage. Strictly speaking, we do not claim an official conformance to MTB, but just to adhere to the multi-tenancy requirements and best practices promoted by MTB.
|MTB Benchmark |MTB Profile|Capsule Version|Conformance|Notes |
|--------------|-----------|---------------|-----------|-------|
|[Block access to cluster resources](block-access-to-cluster-resources.md)|L1|v0.1.0|✓|---|
|[Block access to multitenant resources](block-access-to-multitenant-resources.md)|L1|v0.1.0|✓|---|
|[Block access to other tenant resources](block-access-to-other-tenant-resources.md)|L1|v0.1.0|✓|MTB draft|
|Block add capabilities|L1|v0.1.0|✓|---|
|Require always imagePullPolicy|L1|v0.1.0|✓|---|
|Require run as non-root user|L1|v0.1.0|✓|---|
|Block privileged containers|L1|v0.1.0|✓|---|
|Block privilege escalation|L1|v0.1.0|✓|---|
|Configure namespace resource quotas|L1|v0.1.0|✓|---|
|Configure namespace object limits|L1|v0.1.0|✓|---|
|Block use of host path volumes|L1|v0.1.0|✓|---|
|Block use of NodePort services|L1|v0.1.0|✓|---|
|Block use of host networking and ports|L1|v0.1.0|✓|---|
|Block use of host PID|L1|v0.1.0|✓|---|
|Block use of host IPC|L1|v0.1.0|✓|---|
|Block modification of resource quotas|L1|v0.1.0|✓|---|
|Require PersistentVolumeClaim for storage|L1|v0.1.0|✓|MTB draft|
|Require PV reclaim policy of delete|L1|v0.1.0|✓|MTB draft|
|Block use of existing PVs|L1|v0.1.0|✓|MTB draft|
|Block network access across tenant namespaces|L1|v0.1.0|✓|MTB draft|
|Allow self-service management of Network PoliciesL2|v0.1.0|✓|---|
|Allow self-service management of RolesL2|v0.1.0|✓|MTB draft|
|Allow self-service management of Roles Bindings|L2|v0.1.0|✓|MTB draft|