diff --git a/pentesting/pentesting-kubernetes/README.md b/pentesting/pentesting-kubernetes/README.md index 2614725c..ef9902fd 100644 --- a/pentesting/pentesting-kubernetes/README.md +++ b/pentesting/pentesting-kubernetes/README.md @@ -59,10 +59,6 @@ When a pod creates data that shouldn't be lost when the pod disappear it should * When request that doesn't match any ingress rule is received, the ingress controller will direct it to the "**Default backend**". You can `describe` the ingress controller to get the address of this parameter. * `minikube addons enable ingress` -### How pods communicate with each other - -![](https://sickrov.github.io/media/Screenshot-67.jpg) - ### PKI infrastructure - Certificate Authority CA: ![](https://sickrov.github.io/media/Screenshot-66.jpg) @@ -336,6 +332,21 @@ kube-system Active 1d kubectl create namespace my-namespace ``` +{% hint style="info" %} +Note that most Kubernetes resources \(e.g. pods, services, replication controllers, and others\) are in some namespaces. However, other resources like namespace resources and low-level resources, such as nodes and persistenVolumes are not in a namespace. To see which Kubernetes resources are and aren’t in a namespace: + +```bash +kubectl api-resources --namespaced=true #In a namespace +kubectl api-resources --namespaced=false #Not in a namespace +``` +{% endhint %} + +You can save the namespace for all subsequent kubectl commands in that context. + +```bash +kubectl config set-context --current --namespace= +``` + ### Helm Helm is the **package manager** for Kubernetes. It allows to package YAML files and distribute them in public and private repositories. These packages are called **Helm Charts**. @@ -348,6 +359,8 @@ Helm is also a template engine that allows to generate config files with variabl ![](../../.gitbook/assets/image%20%28465%29.png) + + ## PART 2 - VULNERABILITIES and some fixes. ### Enumeration inside a Pod @@ -821,13 +834,26 @@ kubectl logs app -C proxy More info at: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) -## PART 3 - HARDENING. +## CLUSTER HARDENING - RBAC -### CLUSTER HARDENING - RBAC +Kubernetes has an **authorization module named Role-Based Access Control** \([**RBAC**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)\) that helps to set utilization permissions to the API server. +The RBAC table is constructed from “**Roles**” and “**ClusterRoles**.” The difference between them is just where the role will be applied – a “Role” will grant access to only one specific namespace, while a “ClusterRole” can be used in all namespaces in the cluster. -[https://kubernetes.io/docs/reference/access-authn-authz/rbac/](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) **RBAC** = Role-based access control \(RBAC\) is a method of regulating access to a computer or network resources based on the roles of individual users within your organization. RBAC authorization uses the rbac.authorization.k8s.io API group to drive authorization decisions, allowing you to dynamically configure policies through the Kubernetes API +### RBAC Structure -To enable RBAC, start the API server with the –authorization-mode flag set to a comma-separated list that includes RBAC; for example: +RBAC’s permission is built from three individual parts: + +1. **Role\ClusterRole ­–** The actual permission. It contains _**rules**_ that represent a set of permissions. Each rule contains [resources](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types) and [verbs](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb). The verb is the action that will apply on the resource. +2. **Subject \(User, Group or ServiceAccount\) –** The object that will receive the permissions. +3. **RoleBinding\ClusterRoleBinding –** The connection between Role\ClusterRole and the subject. + +This is what it will look like in a real cluster: + +![](https://www.cyberark.com/wp-content/uploads/2018/12/rolebiding_serviceaccount_and_role-1024x551.png) + +“**Fine-grained** role bindings **provide greater security**, but **require more effort to administrate**." + +From **Kubernetes** 1.6 onwards, **RBAC** policies are **enabled by default**. ****But to enable RBAC you can use something like: ```text kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options @@ -840,54 +866,9 @@ This is enabled by default. RBAC functions: * Permissions are purely additive \(there are no “deny” rules\). * RBAC works with Roles and Bindings -The principle of Least Privilege is the meaning of only access to data or information when is necessary for a legitimate purpose. - -**Types of resources:** - -[https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) - -#### **CONCEPT OF NAMESPACES:** - -Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called **namespaces**. These are intended for use in environments with many users spread across multiple teams, or projects. For clusters with a few to tens of users, you should not need to create or think about namespaces at all. Start using namespaces when you need the features they provide. - -Namespaces provide a scope for names. Names of resources need to be unique within a namespace, but not across namespaces. Namespaces cannot be nested inside one another and each Kubernetes resource can only be in one namespace. - -**VIEWING NAMESPACES:** - -You can list the current namespaces in a cluster using: - -```text -kubectl get namespace -NAME STATUS AGE -default Active 1d -kube-node-lease Active 1d -kube-public Active 1d -kube-system Active 1d -``` - -#### **SETTING THE NAMESPACE PREFERENCE** - -You can permanently save the namespace for all subsequent kubectl commands in that context. - -```bash -kubectl config set-context --current --namespace= -``` - -Not All Objects are in a Namespace. Most Kubernetes resources \(e.g. pods, services, replication controllers, and others\) are in some namespaces. However, namespace resources are not themselves in a namespace. And low-level resources, such as nodes and persistentVolumes, are not in any namespace. - -To see which Kubernetes resources are and aren’t in a namespace: - -**IN A NAMESPACE** - -```bash -kubectl api-resources --namespaced=true -``` - -**NOT IN A NAMESPACE** - -```text -kubectl api-resources --namespaced=false -``` +{% hint style="info" %} +When configuring roles and permissions it's highly important to always follow the principle of Least Privileges +{% endhint %} #### Difference between Role and ClusterRole: diff --git a/pentesting/pentesting-kubernetes/enumeration-from-a-pod.md b/pentesting/pentesting-kubernetes/enumeration-from-a-pod.md index faece698..bb24631b 100644 --- a/pentesting/pentesting-kubernetes/enumeration-from-a-pod.md +++ b/pentesting/pentesting-kubernetes/enumeration-from-a-pod.md @@ -33,22 +33,7 @@ _**Hot pods are**_ pods containing a privileged service account token. A privile ## RBAC -Kubernetes has an authorization module named Role-Based Access Control \(RBAC\) that helps to set utilization permissions to the API server. -The RBAC table is constructed from “Roles” and “ClusterRoles.” The difference between them is just where the role will be applied – a “Role” will grant access to only one specific namespace, while a “ClusterRole” can be used in all namespaces in the cluster. -### RBAC Structure - -RBAC’s permission is built from three individual parts: - -1. **Role\ClusterRole ­–** The actual permission. It contains _**rules**_ that represent a set of permissions. Each rule contains [resources](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types) and [verbs](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb). The verb is the action that will apply on the resource. -2. **Subject \(User, Group or ServiceAccount\) –** The object that will receive the permissions. -3. **RoleBinding\ClusterRoleBinding –** The connection between Role\ClusterRole and the subject. - -This is what it will look like in a real cluster: - -![](https://www.cyberark.com/wp-content/uploads/2018/12/rolebiding_serviceaccount_and_role-1024x551.png) - -“**Fine-grained** role bindings **provide greater security**, but **require more effort to administrate**." ## Risky Permissions