kube-tarian/tarianAgente de segurança runtime baseado em eBPF para Kubernetes que detecta processos desconhecidos e alterações em arquivos, impõe restrições pré-registradas e automatiza a exclusão de pods ou o alerta para mitigar ransomware e outros ataques.
Proteja suas aplicações executando em Kubernetes contra ataques maliciosos pré-registrando seus processos confiáveis e assinaturas de arquivos confiáveis. O Tarian detectará processos desconhecidos e alterações nos arquivos registrados, então enviará alertas e tomará uma ação automatizada. Salve seu ambiente K8s de Ransomware!
Queremos manter este projeto como código aberto para lutar contra os ataques ao nosso ecossistema Kubernetes favorito. Com contribuição contínua, podemos combater ameaças juntos como comunidade.
Como o Tarian funciona?
O Cluster Agent do Tarian é executado no cluster Kubernetes detectando processos desconhecidos e mudanças desconhecidas em arquivos, reportando-os ao Servidor Tarian e, opcionalmente, tomando uma ação: deletar o pod violado. Ele usa eBPF para detectar novos processos. Para detecção de alterações em arquivos, o Cluster Agent do Tarian injeta um container sidecar no pod da sua aplicação principal que verificará os checksums dos arquivos no caminho configurado e os comparará com os checksums registrados no Servidor Tarian. O Tarian fará parte do pod da sua aplicação desde o ambiente de desenvolvimento até o de produção, permitindo que você registre no seu banco de dados Tarian o que deve estar acontecendo e executando no seu container + assinaturas de arquivos a serem monitoradas + o que pode ser notificado + ação a ser tomada (autodestruir o pod) com base nas mudanças detectadas. Faça o shift-left do seu mecanismo de detecção!
E se uma mudança desconhecida ocorrer dentro do container que não está no banco de registro do Tarian, como o Tarian reage a ela?
Se uma mudança desconhecida ocorrer, o Tarian pode simplesmente notificar análises observadas à sua Equipe de Segurança. Então seus Engenheiros de Segurança podem registrar essa mudança no banco de dados Tarian, seja considerada uma ameaça ou não. Além disso, com base na análise, eles podem configurar qual ação tomar quando essa mudança ocorrer novamente.
Como a contribuição da comunidade ajuda a combater as ameaças através do Tarian?
Qualquer nova detecção analisada e marcada como ameaça por seus Especialistas em Segurança, se eles escolherem, pode ser compartilhada com o banco de dados da comunidade open-source Tarian com todos os logs, strings a serem procuradas, observação, transparência, ações a configurar, etc. Basicamente, tudo que os Especialistas quiserem alertar e compartilhar com a comunidade. Você pode usar essas informações como usuário do Tarian e configurar ações no aplicativo Tarian usado no seu ambiente. Este é basicamente um mecanismo para compartilhar informações sobre ameaças e o que fazer com elas. Isso ajuda todos que usam o Tarian a agirem juntos em seus respectivos ambientes K8s, compartilhando conhecimento e experiência.
Que tipo(s) de ação(ões) o Tarian tomaria com base em ameaça(s) conhecida(s)?
O Tarian simplesmente autodestruiria o pod no qual está executando. Se o malware/vírus se espalhar para o resto do ambiente, bem, você sabe o que acontece. Então, o Tarian é basicamente projetado para ajudar a reduzir o risco ao máximo, destruindo pods. O provisionamento de um novo pod será tratado pelo deployment do K8s. O Tarian só fará a destruição dos pods se você instruí-lo a fazê-lo. Se você não quiser que nenhuma ação ocorra, não precisa configurar ou acionar nenhuma; você pode simplesmente dizer ao Tarian para apenas notificá-lo. O Tarian basicamente faz o que você deseja para reduzir o risco.
Por que outra nova ferramenta de segurança quando já existem muitas ferramentas disponíveis, como Falco, Kube-Hunter, Kube-Bench, Calico Enterprise Security e muitas outras ferramentas de segurança (open-source e comerciais) que podem detectar e prevenir ameaças em nível de rede, infraestrutura e aplicação? Por que o Tarian?
A principal razão pela qual o Tarian nasceu é para combater ameaças no Kubernetes juntos como comunidade. Outra razão foi: e se ainda existir algum ataque sofisticado capaz de penetrar em todas as camadas da sua segurança, capaz de alcançar sua aplicação em tempo de execução (Remote Code Execution) e seus volumes de armazenamento, e capaz de se espalhar para danificar ou bloquear sua infraestrutura e dados?! O que você quer fazer sobre tais ataques, especialmente aqueles que se transformam em ransomware? O Tarian é projetado para reduzir esses riscos, tomando ação(ões). Sabemos que o Tarian não é a solução definitiva, mas estamos confiantes de que pode ajudar a reduzir riscos, especialmente quando o conhecimento é compartilhado continuamente pela comunidade. De uma perspectiva técnica, o Tarian pode ajudar a reduzir o risco destruindo os recursos infectados.
kubectl create namespace tarian-system
Você pode usar qualquer opção de instalação Dgraph desde que seja acessível a partir do servidor 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
Baixe o binário tarianctl da página de releases do GitHub.
Execute:
tarianctl install
Você pode usar as seguintes flags para personalizar sua instalação.
Install Tarian on Kubernetes.
Usage:
tarianctl install [flags]
Flags:
--agents-values strings Path to the helm values file for Tarian Cluster Agent and Node agent .
--charts string Path to the tarian helm charts directory.
--dgraph-values strings Path to the helm values file for DGraph.
-h, --help help for install
-n, --namespace string Namespace to install Tarian. (default "tarian-system")
--nats-values strings Path to the helm values file for Nats.
--server-values strings Path to the helm values file for Tarian Server.
Global Flags:
-k, --kubeconfig string path to the kubeconfig file to use
-e, --log-formatter string valid log formatters: json, text(default) (default "text")
-l, --log-level string valid log levels: debug, info(default), warn/warning, error, fatal (default "info")
-s, --server-address string tarian server address to communicate with (default "localhost:50051")
-c, --server-tls-ca-file string ca file that server uses for TLS connection
-t, --server-tls-enabled if enabled, it will communicate with the server using TLS
-i, --server-tls-insecure-skip-verify if set to true, it will skip server's certificate chain and hostname verification (default true)
Veja os valores do helm chart para
O cluster GKE privado por padrão cria regras de firewall para restringir a comunicação do master com os nós apenas nas portas 443 e 10250.
Para injetar o container tarian-pod-agent, o tarian usa um webhook de admissão mutante. O servidor webhook é executado na porta 9443. Portanto, precisamos
criar uma nova regra de firewall para permitir tráfego de entrada da faixa de endereços IP do master para os nós na porta TCP 9443.
Para mais detalhes, veja a documentação do GKE sobre este tópico: 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
Depois que as constraints forem criadas, injetamos o tarian-pod-agent no pod adicionando uma anotação:
metadata:
annotations:
pod-agent.k8s.tarian.dev/threat-scan: "true"
O pod com esta anotação terá um container adicional injetado (tarian-pod-agent). O container tarian-pod-agent irá
verificar continuamente o ambiente de execução com base nas constraints registradas. Qualquer violação será reportada, que será
acessível com 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
# Aguarde ficar pronto
kubectl wait --for=condition=ready pod nginx
# Simule a execução de um processo desconhecido
kubectl exec -ti nginx -c nginx -- sleep 15
# Você deve ver isso reportado no tarian
tarianctl get events
O Tarian vem com o Prometheus Alert Manager por padrão. Se você quiser usar outra instância do 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
Para desabilitá-lo, você pode definir o valor alertManagerAddress como vazio.
Quando o tarian-pod-agent é executado no modo de registro, em vez de reportar processos e arquivos desconhecidos como violações, ele os registra automaticamente como uma nova constraint. Isso é conveniente para economizar tempo de registro manual.
Para habilitar o registro de constraints, o cluster-agent precisa ser configurado.
helm install tarian-cluster-agent tarian/tarian-cluster-agent --devel -n tarian-system \
--set clusterAgent.enableAddConstraint=true
metadata:
annotations:
# registra tanto processos quanto checksums de arquivos
pod-agent.k8s.tarian.dev/register: "processes,files"
# ignora caminhos específicos do registro automático
pod-agent.k8s.tarian.dev/register-file-ignore-paths: "/usr/share/nginx/**/*.txt"
O registro automático de constraints também pode ser feito em um cluster de dev/staging, para que haja menos alterações em produção.
metadata:
annotations:
# especifica com que frequência o tarian-pod-agent deve verificar o checksum do arquivo
pod-agent.k8s.tarian.dev/file-validation-interval: "1m"
Para proteger o tarian-server com TLS, crie um secret contendo o certificado TLS. Você pode criar o secret manualmente, ou usando o Cert Manager. Depois de ter o secret, você pode passar o nome para o valor do helm chart:
helm upgrade -i tarian-server tarian/tarian-server --devel -n tarian-system \
--set server.tlsSecretName=tarian-server-tls
Veja docs/contributing.md
Veja CODE_OF_CONDUCT.md
Veja MAINTAINERS.md
| Ambiente | Funcionando | Observações |
|---|
| 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 |