kube-tarian/tarianeBPF-агент безопасности времени выполнения для Kubernetes, который обнаруживает неизвестные процессы и изменения файлов, применяет предварительно зарегистрированные ограничения и автоматизирует удаление подов или оповещение для смягчения программ-вымогателей и других атак.
Защитите ваши приложения, работающие на Kubernetes, от вредоносных атак, предварительно зарегистрировав доверенные процессы и доверенные сигнатуры файлов. Tarian будет обнаруживать неизвестные процессы и изменения в зарегистрированных файлах, отправлять оповещения и выполнять автоматические действия. Спасите вашу K8s-среду от программ-вымогателей (ransomware)!
Мы стремимся поддерживать этот проект как открытый, чтобы бороться с атаками на нашу любимую экосистему Kubernetes. Благодаря постоянному вкладу сообщества мы можем вместе противостоять угрозам.
Как работает Tarian?
Кластерный агент Tarian (Tarian Cluster Agent) работает в кластере Kubernetes, обнаруживая неизвестные процессы и неизвестные изменения файлов, сообщая о них на сервер Tarian и, при необходимости, выполняя действие: удаление нарушенного пода. Для обнаружения новых процессов он использует eBPF. Для обнаружения изменений файлов Tarian Cluster Agent внедряет sidecar-контейнер в под вашего основного приложения, который проверяет контрольные суммы файлов в заданном пути и сравнивает их с зарегистрированными контрольными суммами на сервере Tarian. Tarian будет частью пода вашего приложения на всём пути от разработки до production, поэтому вы можете зарегистрировать в своей БД Tarian то, что должно происходить и выполняться в вашем контейнере, а также сигнатуры файлов для отслеживания, что может быть уведомлено и какое действие предпринять (самоуничтожение пода) при обнаружении изменений. Сдвиньте свой механизм обнаружения влево!
Что произойдет, если внутри контейнера произойдет неизвестное изменение, которого нет в регистрационной БД Tarian?
Если происходит неизвестное изменение, Tarian может просто уведомить аналитику наблюдений вашу группу безопасности. Тогда ваши инженеры по безопасности могут зарегистрировать это изменение в БД Tarian — считать его угрозой или нет. Кроме того, на основе анализа они могут настроить действие, которое будет выполнено при повторном возникновении этого изменения.
Как вклад сообщества помогает бороться с угрозами через Tarian?
Любое новое обнаружение, проанализированное и помеченное как угроза вашими экспертами по безопасности, если они того пожелают, может быть передано в открытую БД сообщества Tarian со всеми журналами, строками для поиска, наблюдениями, прозрачностью, настраиваемыми действиями и т. д. — в общем, всем, чем эксперты хотят предупредить сообщество и поделиться. Вы как пользователь Tarian можете использовать эту информацию и настраивать действия в приложении Tarian, развернутом в вашей среде. По сути, это механизм обмена информацией об угрозах и о том, что с ними делать. Это помогает всем, кто использует Tarian, действовать сообща в своих средах K8s, делясь знаниями и опытом.
Какие действия предпримет Tarian на основе известной угрозы (угроз)?
Tarian просто самоуничтожит под, в котором работает. Если вредоносное ПО/вирус распространится на остальную среду — вы знаете, что произойдет. Таким образом, Tarian в первую очередь предназначен для максимально возможного снижения риска путем уничтожения подов. Обеспечение нового пода будет выполнено средствами развертывания K8s. Tarian будет уничтожать поды только в том случае, если вы укажете ему это делать. Если вы не хотите никаких действий, вы можете не настраивать и не запускать их; можно просто сказать Tarian только уведомлять вас. По сути, Tarian делает то, что вы хотите, чтобы снизить риск.
Зачем еще один инструмент безопасности, если уже есть множество доступных инструментов, таких как Falco, Kube-Hunter, Kube-Bench, Calico Enterprise Security и многие другие (как открытые, так и коммерческие), которые могут обнаруживать и предотвращать угрозы на уровне сети, инфраструктуры и приложений? Зачем нужен Tarian?
Основная причина появления Tarian — борьба с угрозами в Kubernetes сообща. Другая причина: что, если все еще существуют сложные атаки, способные проникнуть через каждый уровень безопасности, добраться до вашего рабочего приложения (удаленное выполнение кода) и ваших томов хранения, и способные распространяться, чтобы повредить или заблокировать вашу инфраструктуру и данные? Что вы хотите делать с такими атаками, особенно если они превращаются в программы-вымогатели? Tarian предназначен для снижения таких рисков путем выполнения действий. Мы знаем, что Tarian не является окончательным решением, но мы уверены, что он может помочь снизить риски, особенно если знания постоянно передаются сообществом. С технической точки зрения Tarian может снизить риск путем уничтожения зараженных ресурсов.
kubectl create namespace tarian-system
Вы можете использовать любой вариант установки Dgraph, если он доступен с сервера tarian.
helm repo add tarian https://kube-tarian.github.io/helm-charts
helm repo update
helm upgrade -i tarian-server tarian/tarian-server --devel -n tarian-system --set server.dgraph.address=DGRAPH_ADDRESS:PORT
helm upgrade -i tarian-cluster-agent tarian/tarian-cluster-agent --devel -n tarian-system
kubectl wait --for=condition=ready pod --all -n tarian-system
kubectl exec -ti deploy/tarian-server -n tarian-system -- ./tarian-server dgraph apply-schema
Скачайте бинарный файл tarianctl со страницы релизов GitHub.
Запустите:
tarianctl install
Вы можете использовать следующие флаги для настройки установки.
Установить Tarian в Kubernetes.
Использование:
tarianctl install [flags]
Флаги:
--agents-values strings Путь к файлу значений Helm для Tarian Cluster Agent и Node agent.
--charts string Путь к каталогу с чартами Helm tarian.
--dgraph-values strings Путь к файлу значений Helm для DGraph.
-h, --help справка по install
-n, --namespace string Пространство имен для установки Tarian. (по умолчанию "tarian-system")
--nats-values strings Путь к файлу значений Helm для Nats.
--server-values strings Путь к файлу значений Helm для Tarian Server.
Глобальные флаги:
-k, --kubeconfig string путь к файлу kubeconfig для использования
-e, --log-formatter string допустимые форматы логов: json, text (по умолчанию "text")
-l, --log-level string допустимые уровни логов: debug, info (по умолчанию), warn/warning, error, fatal (по умолчанию "info")
-s, --server-address string адрес сервера tarian для связи (по умолчанию "localhost:50051")
-c, --server-tls-ca-file string файл CA, который сервер использует для TLS-соединения
-t, --server-tls-enabled если включено, будет использовать TLS для связи с сервером
-i, --server-tls-insecure-skip-verify если установлено в true, будет пропускать проверку цепочки сертификатов и имени хоста сервера (по умолчанию true)
См. значения Helm-чартов для
По умолчанию частный кластер GKE создает правила брандмауэра, которые ограничивают связь мастера с узлами только портами 443 и 10250.
Для внедрения контейнера tarian-pod-agent Tarian использует мутирующий вебхук приема (admission webhook). Вебхук-сервер работает на порту 9443. Поэтому необходимо
создать новое правило брандмауэра, разрешающее входящий трафик из диапазона IP-адресов мастера к узлам на TCP порт 9443.
Подробнее см. в документации GKE по этой теме: https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters#add_firewall_rules.
kubectl port-forward svc/tarian-server -n tarian-system 41051:80
export TARIAN_SERVER_ADDRESS=localhost:41051
tarianctl get events
tarianctl add constraint --name nginx --namespace default \
--match-labels run=nginx \
--allowed-processes=pause,tarian-pod-agent,nginx
tarianctl get constraints
tarianctl add constraint --name nginx-files --namespace default \
--match-labels run=nginx \
--allowed-file-sha256sums=/usr/share/nginx/html/index.html=38ffd4972ae513a0c79a8be4573403edcd709f0f572105362b08ff50cf6de521
tarianctl get constraints
После создания ограничений мы внедряем tarian-pod-agent в под, добавив аннотацию:
metadata:
annotations:
pod-agent.k8s.tarian.dev/threat-scan: "true"
Под с такой аннотацией получит дополнительный контейнер (tarian-pod-agent). Контейнер tarian-pod-agent будет
непрерывно проверять среду выполнения на основе зарегистрированных ограничений. Любые нарушения будут зарегистрированы; их можно просмотреть с помощью tarianctl get events.
kubectl apply -f https://raw.githubusercontent.com/kube-tarian/tarian/main/dev/config/monitored-pod/configmap.yaml
kubectl apply -f https://raw.githubusercontent.com/kube-tarian/tarian/main/dev/config/monitored-pod/pod.yaml
# дождитесь готовности
kubectl wait --for=condition=ready pod nginx
# симулируйте запуск неизвестного процесса
kubectl exec -ti nginx -c nginx -- sleep 15
# вы должны увидеть отчет в tarian
tarianctl get events
По умолчанию Tarian поставляется с Prometheus Alert Manager. Если вы хотите использовать другой экземпляр Alert Manager:
helm install tarian-server tarian/tarian-server --devel \
--set server.alert.alertManagerAddress=http://alertmanager.monitoring.svc:9093 \
--set alertManager.install=false \
-n tarian-system
Чтобы отключить его, установите значение alertManagerAddress пустым.
Когда tarian-pod-agent работает в режиме регистрации, он не сообщает о неизвестных процессах и файлах как о нарушениях, а автоматически регистрирует их как новое ограничение. Это удобно, чтобы сэкономить время на ручной регистрации.
Чтобы включить регистрацию ограничений, необходимо настроить cluster-agent.
helm install tarian-cluster-agent tarian/tarian-cluster-agent --devel -n tarian-system \
--set clusterAgent.enableAddConstraint=true
metadata:
annotations:
# регистрировать как процессы, так и контрольные суммы файлов
pod-agent.k8s.tarian.dev/register: "processes,files"
# игнорировать определенные пути при автоматической регистрации
pod-agent.k8s.tarian.dev/register-file-ignore-paths: "/usr/share/nginx/**/*.txt"
Автоматическую регистрацию ограничений также можно выполнять в dev/staging кластере, чтобы в production было меньше изменений.
metadata:
annotations:
# указывает, как часто tarian-pod-agent должен проверять контрольную сумму файла
pod-agent.k8s.tarian.dev/file-validation-interval: "1m"
Чтобы защитить tarian-server с помощью TLS, создайте секрет, содержащий TLS-сертификат. Вы можете создать секрет вручную или с помощью Cert Manager. После того как секрет будет готов, передайте его имя в значение Helm-чарта:
helm upgrade -i tarian-server tarian/tarian-server --devel -n tarian-system \
--set server.tlsSecretName=tarian-server-tls
См. MAINTAINERS.md
| Окружение | Работает | Примечания |
|---|
| Kind v0.14.0 | ✔️ | |
| Minikube v1.26.0 | ✔️ | |
| Linode Kubernetes Engine (LKE) 1.22 | ✔️ | |
| Digital Ocean Kubernetes Engine (DOKS) 1.22 | ✔️ | |
| Google Kubernetes Engine (GKE) 1.22 | ✔️ | |
| Amazon Elastic Kubernetes Engine (EKS) | ➖ | kernel < 5.8 |
| Azure Kubernetes Service (AKS) | ➖ | kernel < 5.8 |