Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az

This commit is contained in:
Translator
2024-12-31 19:09:02 +00:00
parent 7770a50092
commit 4ecda9fe96
244 changed files with 8478 additions and 11318 deletions

View File

@@ -1,106 +1,94 @@
# Kubernetes ValidatingWebhookConfiguration
**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
**Автором цієї сторінки є** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## Definition
## Визначення
ValidatingWebhookConfiguration is a Kubernetes resource that defines a validating webhook, which is a server-side component that validates incoming Kubernetes API requests against a set of predefined rules and constraints.
ValidatingWebhookConfiguration - це ресурс Kubernetes, який визначає валідаційний вебхук, що є компонентом на стороні сервера, який перевіряє вхідні запити API Kubernetes на відповідність набору попередньо визначених правил і обмежень.
## Purpose
## Мета
The purpose of a ValidatingWebhookConfiguration is to define a validating webhook that will enforce a set of predefined rules and constraints on incoming Kubernetes API requests. The webhook will validate the requests against the rules and constraints defined in the configuration, and will return an error if the request does not conform to the rules.
Мета ValidatingWebhookConfiguration полягає в тому, щоб визначити валідаційний вебхук, який буде забезпечувати дотримання набору попередньо визначених правил і обмежень для вхідних запитів API Kubernetes. Вебхук перевірятиме запити на відповідність правилам і обмеженням, визначеним у конфігурації, і поверне помилку, якщо запит не відповідає правилам.
**Example**
Here is an example of a ValidatingWebhookConfiguration:
**Приклад**
Ось приклад ValidatingWebhookConfiguration:
```yaml
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: example-validation-webhook
namespace: default
name: example-validation-webhook
namespace: default
webhook:
name: example-validation-webhook
clientConfig:
url: https://example.com/webhook
serviceAccountName: example-service-account
rules:
- apiGroups:
- ""
apiVersions:
- "*"
operations:
- CREATE
- UPDATE
resources:
- pods
name: example-validation-webhook
clientConfig:
url: https://example.com/webhook
serviceAccountName: example-service-account
rules:
- apiGroups:
- ""
apiVersions:
- "*"
operations:
- CREATE
- UPDATE
resources:
- pods
```
The main difference between a ValidatingWebhookConfiguration and policies : 
Основна різниця між ValidatingWebhookConfiguration та політиками : 
<figure><img src="../../images/Kyverno.png" alt=""><figcaption><p>Kyverno.png</p></figcaption></figure>
- **ValidatingWebhookConfiguration (VWC)** : A Kubernetes resource that defines a validating webhook, which is a server-side component that validates incoming Kubernetes API requests against a set of predefined rules and constraints.
- **Kyverno ClusterPolicy**: A policy definition that specifies a set of rules and constraints for validating and enforcing Kubernetes resources, such as pods, deployments, and services
- **ValidatingWebhookConfiguration (VWC)** : Ресурс Kubernetes, який визначає валідаційний вебхук, що є компонентом на стороні сервера, який перевіряє вхідні запити API Kubernetes на відповідність набору попередньо визначених правил і обмежень.
- **Kyverno ClusterPolicy**: Визначення політики, яке специфікує набір правил і обмежень для валідації та забезпечення ресурсів Kubernetes, таких як поди, деплойменти та сервіси
## Enumeration
```
$ kubectl get ValidatingWebhookConfiguration
```
### Зловживання Kyverno та Gatekeeper VWC
### Abusing Kyverno and Gatekeeper VWC
Як ми можемо бачити, всі встановлені оператори мають принаймні один ValidatingWebHookConfiguration(VWC).
As we can see all operators installed have at least one ValidatingWebHookConfiguration(VWC).
**Kyverno** та **Gatekeeper** є обома механізмами політики Kubernetes, які надають структуру для визначення та впровадження політик у кластері.
**Kyverno** and **Gatekeeper** are both Kubernetes policy engines that provide a framework for defining and enforcing policies across a cluster.
Виключення стосуються конкретних правил або умов, які дозволяють обійти або змінити політику за певних обставин, але це не єдиний спосіб!
Exceptions refer to specific rules or conditions that allow a policy to be bypassed or modified under certain circumstances but this is not the only way !
Для **kyverno**, оскільки є дійсна політика, вебхук `kyverno-resource-validating-webhook-cfg` заповнюється.
For **kyverno**, as you as there is a validating policy, the webhook `kyverno-resource-validating-webhook-cfg` is populated.
Для Gatekeeper є YAML файл `gatekeeper-validating-webhook-configuration`.
For Gatekeeper, there is `gatekeeper-validating-webhook-configuration` YAML file.
Both come from with default values but the Administrator teams might updated those 2 files.
### Use Case
Обидва мають значення за замовчуванням, але команди адміністраторів можуть оновити ці 2 файли.
### Використання
```bash
$ kubectl get validatingwebhookconfiguration kyverno-resource-validating-webhook-cfg -o yaml
```
Now, identify the following output :
Тепер визначте наступний вихід:
```yaml
namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values:
- default
- TEST
- YOYO
- kube-system
- MYAPP
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values:
- default
- TEST
- YOYO
- kube-system
- MYAPP
```
Тут мітка `kubernetes.io/metadata.name` відноситься до назви простору імен. Простори імен з назвами в списку `values` будуть виключені з політики:
Here, `kubernetes.io/metadata.name` label refers to the namespace name. Namespaces with names in the `values` list will be excluded from the policy :
Перевірте наявність просторів імен. Іноді, через автоматизацію або неправильну конфігурацію, деякі простори імен могли не бути створені. Якщо у вас є дозвіл на створення простору імен, ви можете створити простір імен з назвою в списку `values`, і політики не будуть застосовуватися до вашого нового простору імен.
Check namespaces existence. Sometimes, due to automation or misconfiguration, some namespaces might have not been created. If you have permission to create namespace, you could create a namespace with a name in the `values` list and policies won't apply your new namespace.
The goal of this attack is to exploit **misconfiguration** inside VWC in order to bypass operators restrictions and then elevate your privileges with other techniques
Мета цієї атаки полягає в тому, щоб експлуатувати **неправильну конфігурацію** всередині VWC, щоб обійти обмеження операторів, а потім підвищити свої привілеї за допомогою інших технік.
{{#ref}}
abusing-roles-clusterroles-in-kubernetes/
{{#endref}}
## References
## Посилання
- [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
- [https://kyverno.io/](https://kyverno.io/)
- [https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)