← [Раздел](README.md) · [Главная](../README.md)

# Falco — runtime-безопасность в Kubernetes

## Цель

Понять **runtime security**: обнаружение подозрительного поведения в работающих контейнерах (shell, неожиданные исходящие соединения, чтение `/etc/shadow`) с помощью **Falco** и связи алертов с incident response.

## Предварительно

- Базовый Kubernetes: Pod, Namespace, Deployment.
- Желательно локальный кластер (kind/minikube). Без кластера — достаточно чтения и разбора правил.

## Время

~45 минут (+30 мин на установку в kind).

## Shift left vs runtime

| Этап | Вопрос |
|------|--------|
| CI (Trivy, Semgrep) | Безопасен ли **артефакт** до деплоя? |
| Admission (OPA/Kyverno) | Разрешён ли **такой** pod spec? |
| **Runtime (Falco)** | Ведёт ли себя процесс **нормально** после старта? |

Пример: образ без CVE, но злоумышленник выполнил `kubectl exec` и запустил reverse shell — это видит runtime.

## Как работает Falco

Falco использует **eBPF** или kernel module (в зависимости от установки) и правила на языке YAML:

- syscall (например, `execve`);
- атрибуты K8s (namespace, pod label);
- условия (бинарь `bash`, parent `nginx`).

Событие → алерт в stdout, Falcosidekick → Slack/Prometheus/Loki.

## Установка в kind (учебная)

```bash
kind create cluster --name falco-learn
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set falcosidekick.enabled=false
kubectl get pods -n falco
```

## Пример правила

`custom-learn.yaml`:

```yaml
- rule: Terminal shell in container
  desc: Обнаружен интерактивный shell в контейнере
  condition: >
    spawned_process and container
    and proc.name in (bash, sh, zsh)
    and not k8s.ns.name in ("kube-system", "falco")
  output: >
    Shell в контейнер (user=%user.name ns=%k8s.ns.name pod=%k8s.pod.name
    cmd=%proc.cmdline)
  priority: WARNING
  tags: [container, mitre_execution]
```

Применение через Helm `customRules` или ConfigMap — см. документацию chart для вашей версии.

## Воспроизведение алерта

```bash
kubectl run demo --image=nginx:alpine --restart=Never
kubectl exec -it demo -- sh -c "id"
```

В логах Falco:

```bash
kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=50
```

Ожидайте правило про shell (встроенные правила Falco также покрывают типичные кейсы).

## Снижение шума

| Подход | Действие |
|--------|----------|
| Allowlist namespace | Исключить `kube-system`, CI runners |
| Макросы | Общие условия в `macro:` |
| Приоритеты | CRITICAL только на exfiltration |
| Baseline | Неделя наблюдения перед блокировками |

Не блокируйте прод на первом дне: сначала **наблюдение**, потом enforcement через response automation.

## Falco + Kubernetes audit

Включите audit policy API server — Falco может коррелировать `kubectl exec` с syscalls.

Минимальная цель audit: кто выполнял exec, apply, delete secret.

## Response playbook (кратко)

1. **Alert** → тикет PagerDuty / Security channel.
2. **Triage** — false positive? известный debug?
3. **Contain** — NetworkPolicy deny egress, scale deployment to 0, isolate node.
4. **Eradicate** — пересобрать образ, ротировать секреты.
5. **Recover** — restore из known-good digest.
6. **Lessons** — новое правило Falco или Kyverno deny `exec`.

Связь с [lab-04](../11-praktikum/lab-04-incident-tabletop.md).

## Метрики

- alerts per namespace per day;
- MTTR на CRITICAL runtime alert;
- % alerts с привязанным тикетом.

## Самопроверка

1. Что runtime-сканер видит, чего не видит Trivy image?
2. Зачем исключать `kube-system` из правил?
3. Какие шаги containment без удаления кластера?
4. Как Falco помогает при компрометации через `kubectl exec`?

## Дальше

[Практикум](../11-praktikum/README.md) — четыре лабораторные с командами.