coelner/hacktricks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

GitBook: [master] 2 pages modified

Browse Source
This commit is contained in:
CPol 2021-04-28 13:49:35 +00:00 committed by gitbook-bot
parent 2d5784f543
commit 87ea9b42a0
No known key found for this signature in database
GPG Key ID: 07D2180C7B12D0FF
2 changed files with 37 additions and 71 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

93
pentesting/pentesting-kubernetes/README.md
View File

@ -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=<insert-namespace-name-here>
```
### 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=<insert-namespace-name-here>
```
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: <a id="difference-between-role-and-clusterrole"></a>

15
pentesting/pentesting-kubernetes/enumeration-from-a-pod.md
View File

@ -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