kube-tarian/tarianKubernetes向けのeBPFベースのランタイムセキュリティエージェントで、未知のプロセスやファイル変更を検出し、事前登録された制約を適用し、ランサムウェアやその他の攻撃を軽減するためにポッドの削除やアラートを自動化します。
Kubernetes上で動作するアプリケーションを、信頼できるプロセスとファイル署名を事前登録することで悪意のある攻撃から保護します。Tarianは未知のプロセスや登録済みファイルへの変更を検出し、アラートを送信して自動化されたアクションを実行します。K8s環境をランサムウェアから守りましょう！
私たちはこのプロジェクトをオープンソースとして維持し、私たちのお気に入りのKubernetesエコシステムに対する攻撃と戦いたいと考えています。継続的な貢献により、コミュニティとして協力して脅威に立ち向かうことができます。
Tarianの仕組みは？
Tarian Cluster AgentはKubernetesクラスター内で動作し、未知のプロセスやファイルへの未知の変更を検出してTarian Serverに報告し、オプションで違反したPodを削除するアクションを実行します。新しいプロセスの検出にはeBPFを使用します。ファイル変更検出のため、Tarian Cluster AgentはメインアプリケーションのPodにサイドカーコンテナを注入し、設定されたパスでファイルチェックサムを確認し、Tarian Serverに登録されたチェックサムと比較します。Tarianは開発環境から本番環境までアプリケーションのPodの一部となり、コンテナ内で何が行われ、何が実行されるべきか、監視するファイルシグネチャ、通知する内容、検出された変更に基づいて取るべきアクション（Podの自己破壊）をTarian DBに登録できます。検出メカニズムをシフトレフトしましょう！
コンテナ内でTarianの登録DBにない未知の変更が発生した場合、Tarianはどのように反応しますか？
未知の変更が発生した場合、Tarianは観測された分析結果をセキュリティチームに通知することができます。セキュリティエンジニアは、その変更が脅威とみなされるかどうかをTarian DBに登録できます。また、その分析に基づいて、その変更が再度発生した場合に取るべきアクションを設定できます。
コミュニティの貢献は、Tarianを介して脅威と戦うのにどのように役立ちますか？
セキュリティ専門家によって分析され、脅威としてマークされた新しい検出結果は、ログ、探すべき文字列、観察結果、透明性、設定すべきアクションなど、すべてをオープンソースのTarianコミュニティDBと共有することができます（選択した場合）。専門家が警告してコミュニティと共有したいものは基本的に何でも共有可能です。Tarianユーザーはその情報を利用して、自身の環境で使用するTarianアプリケーションでアクションを設定できます。これは脅威とその対処法に関する情報を共有する仕組みです。これにより、Tarianを使用する全員が知識と経験を共有し、それぞれのK8s環境で協力してアクションを実行できます。
Tarianは既知の脅威に基づいてどのようなアクションを実行しますか？
Tarianは、自身が動作しているPodを単純に自己破壊します。マルウェアやウイルスが環境全体に広がった場合の結果はご想像の通りです。そのため、TarianはPodを破壊することでリスクを可能な限り低減するように設計されています。新しいPodのプロビジョニングはK8sのデプロイメントが行います。Tarianは、あなたがそう指示した場合にのみPodの破壊を行います。アクションを実行したくない場合は、設定やトリガーは不要で、Tarianに単に通知するだけの設定も可能です。Tarianは基本的に、リスク低減のためにあなたが望むことを実行します。
Falco、Kube-Hunter、Kube-Bench、Calico Enterprise Securityなど、ネットワーク、インフラ、アプリケーションレベルで脅威を検出・防止できる多くのセキュリティツール（オープンソースおよび商用）がすでに存在するのに、なぜ別の新しいセキュリティツールが必要なのですか？なぜTarianなのですか？
Tarianが生まれた主な理由は、コミュニティとして協力してKubernetesの脅威と戦うことです。もう一つの理由は、すべてのセキュリティ層を突破し、実行中のアプリケーション（リモートコード実行）やストレージボリュームに到達し、インフラやデータを損傷またはロックするために拡散できる高度な攻撃がまだ存在する場合、どうすれば良いか？という問いです。特にランサムウェアに変貌するような攻撃に対して何をすべきでしょうか？Tarianは、アクションを実行することでそのようなリスクを低減するように設計されています。Tarianが究極の解決策ではないことは承知していますが、特にコミュニティが継続的に知識を共有することでリスク低減に役立つと確信しています。技術的な観点から、Tarianは感染したリソースを破壊することでリスク低減に貢献できます。
kubectl create namespace tarian-system
tarianサーバーからアクセス可能であれば、任意のDgraphインストールオプションを使用できます。
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
GitHubリリースページからtarianctlバイナリをダウンロードします。
実行:
tarianctl install
インストールをカスタマイズするには、以下のフラグを使用できます。
TarianをKubernetesにインストールします。
使用法:
tarianctl install [flags]
フラグ:
--agents-values strings Tarian Cluster AgentおよびNode agentのHelm valuesファイルのパス
--charts string tarian Helmチャートディレクトリのパス
--dgraph-values strings DGraphのHelm valuesファイルのパス
-h, --help installに関するヘルプ
-n, --namespace string Tarianをインストールするネームスペース (デフォルト "tarian-system")
--nats-values strings NatsのHelm valuesファイルのパス
--server-values strings Tarian ServerのHelm valuesファイルのパス
グローバルフラグ:
-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 サーバーがTLS接続に使用するCAファイル
-t, --server-tls-enabled 有効にすると、TLSを使用してサーバーと通信します
-i, --server-tls-insecure-skip-verify trueに設定すると、サーバーの証明書チェーンとホスト名の検証をスキップします (デフォルト true)
Helmチャートのvaluesについては以下を参照:
プライベートGKEクラスターはデフォルトで、マスターからノードへの通信をポート443と10250のみに制限するファイアウォールルールを作成します。tarian-pod-agentコンテナを注入するために、tarianはミューテーティングAdmission Webhookを使用します。Webhookサーバーはポート9443で実行されます。そのため、マスターIPアドレス範囲からノードへのTCPポート9443のingressを許可する新しいファイアウォールルールを作成する必要があります。
詳細については、このトピックに関する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
制約を作成したら、アノテーションを追加してPodにtarian-pod-agentを注入します:
metadata:
annotations:
pod-agent.k8s.tarian.dev/threat-scan: "true"
このアノテーションが付いたPodには、追加のコンテナ（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の値を空に設定できます。
docs/troubleshooting.mdを参照してください。
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"
自動制約登録は開発/ステージングクラスターでも実行できるため、本番環境での変更を減らすことができます。
metadata:
annotations:
# tarian-pod-agentがファイルチェックサムを検証する間隔を指定
pod-agent.k8s.tarian.dev/file-validation-interval: "1m"
TLSでtarian-serverを保護するには、TLS証明書を含むシークレットを作成します。シークレットは手動で作成するか、Cert Managerを使用して作成できます。シークレットを作成したら、Helmチャートの値に名前を渡します:
helm upgrade -i tarian-server tarian/tarian-server --devel -n tarian-system \
--set server.tlsSecretName=tarian-server-tls
docs/contributing.mdを参照してください。
CODE_OF_CONDUCT.mdを参照してください。
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 |