Neste documento, descrevemos como instalar e configurar o encaminhador no Linux. É possível instalar o encaminhador em várias distribuições Linux (Debian, Ubuntu, Red Hat, Suse etc.). O Google Cloud fornece o software usando um contêiner do Docker. É possível executar e gerenciar o contêiner do Docker em uma máquina física ou virtual com o Linux.
Personalizar os arquivos de configuração
Com base nas informações enviadas antes da implantação, o Google Cloud fornece o software de encaminhamento e os arquivos de configuração. O Google Cloud configura os arquivos de configuração para a instância do encaminhador na sua rede. Se for necessário mudar a configuração, entre em contato com o suporte do Chronicle.
Requisitos do sistema
Veja a seguir recomendações gerais. Para recomendações específicas para seu sistema, entre em contato com o suporte do Chronicle.
RAM: 1,5 GB para cada tipo de dado coletado. Por exemplo, detecção e resposta de endpoints (EDR), DNS e DHCP são tipos de dados separados. Você precisa de 4,5 GB de RAM para coletar dados para os três.
CPU: duas CPUs são suficientes para processar menos de 10.000 eventos por segundo (EPS,na sigla em inglês) (total para todos os tipos de dados). Se você espera encaminhar mais de 10.000 EPS, provisione de 4 a 6 CPUs.
Disco: 100 MB de espaço em disco é suficiente, independentemente da quantidade de dados processada pelo encaminhador do Chronicle. Consulte também Buffering em disco se você precisar armazenar em buffer as mensagens registradas em disco, em vez de na memória. O encaminhador do Chronicle armazena em buffer a memória por padrão.
Verificar a configuração do firewall
Se você tiver firewalls ou proxies autenticados entre o contêiner do encaminhador do Chronicle e a Internet, eles precisarão de regras para abrir o acesso aos seguintes hosts:
| Tipo de conexão | Destino | Port |
| TCP | malachiteingestion-pa.googleapis.com | 443 |
| TCP | accounts.google.com | 443 |
| TCP | gcr.io | 443 |
Instalar o Docker
Você pode instalar o Docker em vários sistemas operacionais host. A instalação real do Docker depende do ambiente do host. O Google Cloud oferece uma documentação limitada para ajudar você a instalar o Docker em várias distribuições conhecidas do Linux. No entanto, o Docker tem código aberto e uma documentação substancial já está disponível.
Após a instalação do Docker no seu sistema, o restante do processo de instalação do encaminhador Chronicle é idêntico, independentemente da distribuição do Linux que você está usando.
Verifique se o Docker está instalado no sistema executando o seguinte comando (privilégios elevados):
# docker ps
A resposta a seguir indica que o Docker foi instalado corretamente:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
É possível coletar mais informações sobre a instalação do Docker usando o seguinte comando:
# docker info
Se você tiver problemas com o Docker, o suporte do Chronicle poderá solicitar a saída desse comando para ajudar na depuração.
Instalar o encaminhador
Esta seção descreve como instalar o Chronicle Forwarder usando um contêiner do Docker em um sistema Linux.
Etapa 1. Fazer o download, transferir e instalar os arquivos de configuração do encaminhador
O Google Cloud fornece arquivos de configuração do encaminhador específicos do seu sistema operacional (Linux ou Windows). Faça o download dos arquivos no link fornecido pelo representante do Chronicle para um diretório local no seu laptop (por exemplo, chronicle). Depois de concluir as etapas a seguir, transfira os arquivos de configuração do seu laptop para o diretório forward/config do encaminhador no diretório inicial do usuário.
Conecte-se ao encaminhador Linux usando o terminal.
Crie um novo usuário no encaminhador do Linux.
# adduser <username># passwd <username># usermod -aG wheel <username>Altere o diretório para o diretório inicial do novo usuário que executará o contêiner do Docker.
Crie um diretório para armazenar os arquivos de configuração do encaminhador Chronicle:
# mkdir ~/configAlterar o diretório
Depois que os arquivos forem transferidos, confirme se os arquivos de configuração estão localizados no diretório ~/config:
# ls -l
Etapa 2: Instale a chave do Chronicle Container Registry
O arquivo JSON fornecido pelo Google Cloud (com uma extensão .json) contém as credenciais necessárias para acessar o registro do Chronicle Docker.
Copie o texto de comando a seguir (incluindo quebras de linha) para um editor de texto e renomeie o nome do arquivo .json entre colchetes para o nome do arquivo do Chronicle Docker Authentication.
docker login \ -u _json_key \ --password-stdin \ https://gcr.io < ./chronicle-container-c2da10b71454-oneline.jsonDepois que a edição for concluída, copie o texto completo do comando e execute-o no diretório ~/config do encaminhador do Linux.
A resposta ao comando de login do Docker acima deve ser "Login Succeeded".
Se ocorrer um problema, confirme a versão do Docker em execução:
# docker version
Versões mais antigas do Docker (por exemplo, 1.13.1) podem exigir argumentos de linha de comando diferentes. Veja abaixo as diferenças.
Etapa 2 para versões mais antigas do Docker que não são compatíveis com --password-stdin
Para versões mais antigas do Docker (versões que não aceitam --password-stdin), copie o conteúdo do seu arquivo JSON e cole-o no prompt da senha.
Use o comando a seguir:
$ cat ./<filename>.jsonCopie a resposta ao comando cat.
Faça login no Docker:
docker login -u _json_key https://gcr.ioNo prompt
Password:, cole o conteúdo da área de transferência.Independentemente de como você fornecer a senha (
--password-stdinou copiar e colar), a saída do comandodocker loginseráLogin Succeeded.
Etapa 3. Execute o encaminhador no contêiner do Docker
Use os procedimentos a seguir para iniciar o encaminhador do Chronicle pela primeira vez, bem como para fazer upgrade para a versão mais recente do contêiner do Chronicle:
As opções --log-opt estão disponíveis desde o Docker
1.13. Essas opções limitam o tamanho dos arquivos de registros do contêiner e precisam ser usados desde que sua versão do Docker seja compatível.
Se você estiver fazendo upgrade, comece limpando todas as execuções anteriores do Docker. No exemplo a seguir, o nome do contêiner do Docker é
cfpse, em seguida, recebe a imagem do Docker mais recente do Google Cloud com o comando pull do docker abaixo.# docker stop cfps # docker rm cfpsConsiga a imagem mais recente do Docker no Google Cloud:
# docker pull gcr.io/chronicle-container/cf_production_stableInicie o encaminhador do Chronicle no contêiner do Docker:
docker run \ --detach \ --name cfps \ --restart=always \ --log-opt max-size=100m \ --log-opt max-file=10 \ --net=host \ -v ~/config:/opt/chronicle/external \ gcr.io/chronicle-container/cf_production_stable
Esses comandos também são fornecidos como um script de shell chamado run_docker_production_stable.sh.
O contêiner do Docker e o encaminhador do Chronicle persistem após a reinicialização do sistema.
Etapa 4. Monitorar e gerenciar o encaminhador
Os comandos do Docker a seguir ajudam você a monitorar e gerenciar o encaminhador do Chronicle:
Verifique se o contêiner do Docker está em execução:
docker psExiba os registros do contêiner. Isso pode gerar uma quantidade significativa de volume de saída, mas é útil para depuração:
docker logs cfpsPara ver o que está sendo executado no contêiner:
docker top cfpsPara interromper o contêiner:
docker stop cfps
Colete dados do Splunk
É possível configurar o encaminhamento do Chronicle para encaminhar seus dados do Splunk para o Chronicle. O Google Cloud configura o encaminhador do Chronicle com as seguintes informações para encaminhar seus dados do Splunk:
URL da API REST Splunk (por exemplo, https://10.0.113.15:8889).
Consultas do Splunk para gerar dados para cada um dos tipos de dados obrigatórios (por exemplo, index=dns).
Você precisa disponibilizar as credenciais da sua conta do Splunk para o encaminhamento do Chronicle.
Crie um arquivo local para suas credenciais do Splunk e nomeie-o como creds.txt. Coloque o nome de usuário na primeira linha e a senha na segunda linha:
cat creds-file
myusername
mypassword
Para clientes que usam o encaminhador do Chronicle para acessar uma instância do Splunk, copie o arquivo creds.txt para o diretório de configuração (o mesmo diretório dos arquivos de configuração). Exemplo:
cp creds-file ~/config/creds.txt
Verifique se o arquivo creds.txtem está no local adequado:
ls ~/config
Coletar dados syslog
O encaminhador do Chronicle pode operar como um servidor Syslog, o que significa que você pode configurar qualquer dispositivo ou servidor compatível com o envio de dados syslog por uma conexão TCP ou UDP para encaminhar seus dados para o encaminhador Chronicle. É possível controlar exatamente quais dados o dispositivo ou servidor envia ao encaminhador do Chronicle. O encaminhador do Chronicle pode, então, encaminhar os dados para o Chronicle.
O arquivo de configuração (fornecido pelo Google Cloud) especifica quais portas precisam ser monitoradas para cada tipo de dados encaminhados, como a porta 10514. Por padrão, o encaminhador Chronicle aceita conexões TCP e UDP.
Configurar o rsyslog
Para configurar o rsyslog, é necessário especificar um destino para cada porta. Por exemplo, cada tipo de dados. Consulte a sintaxe do sistema para saber a sintaxe correta. Os exemplos a seguir ilustram uma configuração de destino "rsyslog":
Tráfego de registro TCP:
dns.* @192.168.0.12:10514Tráfego de registro UDP:
dns.* @192.168.0.12:10514
Ativar configurações de TLS para syslog
É possível ativar o TLS para a conexão do Syslog com o encaminhador do Chronicle. No arquivo de configuração do encaminhador Chronicle, especifique o local do seu certificado e da sua chave de certificado, conforme mostrado no exemplo a seguir:
| certificado | "/opt/chronicle/external/certs/edb3ae966a7bbe1f.pem" |
| chave de certificado | "/opt/chronicle/external/certs/forwarder.key" |
Com base no exemplo mostrado, a configuração do encaminhador Chronicle seria
modificada da seguinte maneira:
collectors:
- syslog:
common:
enabled: true
data_type: WINDOWS_DNS
data_hint:
batch_n_seconds: 10
batch_n_bytes: 1048576
tcp_address: 0.0.0.0:10515
connection_timeout_sec: 60
certificate: "/opt/chronicle/external/certs/edb3ae966a7bbe1f.pem"
certificate_key: "/opt/chronicle/external/certs/forwarder.key"
É possível criar um diretório de certificados no diretório de configuração e armazenar os arquivos de certificado nele.
Coletar dados do pacote
O encaminhamento do Chronicle pode capturar pacotes diretamente de uma interface de rede usando o libpcap no Linux. Os pacotes são capturados e enviados para o Chronicle em vez de entradas de registro. A captura de pacotes é processada apenas em uma interface local. Para ativar a captura de pacotes para seu sistema, entre em contato com o suporte do Chronicle.
O Google Cloud configura o encaminhador do Chronicle com a expressão Berkeley Packet Filter (BPF) usada na captura de pacotes (por exemplo, a porta 53 e não o localhost).
Alternar compactação de dados
A compactação de registros reduz o consumo de largura de banda da rede ao transferir registros para o Chronicle. No entanto, a compactação pode causar um aumento no uso da CPU. A compensação entre o uso da CPU e a largura de banda depende de muitos fatores, incluindo o tipo de dados de registro, a compactação desses dados, a disponibilidade de ciclos de CPU no host que executa o encaminhador e a necessidade de reduzir a rede }consumo de largura de banda.
Por exemplo, os registros baseados em texto são compactados bem e podem proporcionar uma economia substancial na largura de banda e baixo uso da CPU. No entanto, payloads criptografados de pacotes brutos não compactam bem e geram uso de CPU maior.
Como a maioria dos tipos de registro ingeridos pelo encaminhador é eficiente para compactação, a compactação de registro é ativada por padrão para reduzir o consumo da largura de banda. No entanto, se o aumento do uso da CPU superar o benefício da economia de largura de banda, você poderá desativar a compactação configurando ocompactação campo paraFalso no arquivo de configuração do encaminhador do Chronicle, conforme mostrado no exemplo a seguir:
output:
compression: false
url: malachiteingestion-pa.googleapis.com:443
identity:
identity:
collector_id: 10479925-878c-11e7-9421-10604b7cb5c1
customer_id: ebdc4bb9-878b-11e7-8455-10604b7cb5c1
secret_key: |
{
"type": "service_account",
...
Buffer de disco
O armazenamento em buffer permite armazenar em buffer as mensagens registradas em disco, em vez da memória. As mensagens registradas podem ser armazenadas caso o encaminhador falhe ou o host subjacente falhe. A ativação do armazenamento em buffer do disco pode afetar o desempenho.
Se você estiver executando o Forwarder usando o Docker, o Google recomenda montar um volume separado do volume de configuração para fins de isolamento. Além disso, cada entrada precisa ser isolada com o próprio diretório ou volume para evitar conflitos.
Exemplo de configuração: armazenamento em buffer de disco
A configuração a seguir inclui a sintaxe para ativar o armazenamento em buffer do disco:
collectors:
- syslog:
common:
write_to_disk_buffer_enabled: true
# /buffers/NIX_SYSTEM is part of the external mounted volume for the forwarder
write_to_disk_dir_path: /buffers/NIX_SYSTEM
max_file_buffer_bytes: 1073741824
batch_n_bytes: 1048576
batch_n_seconds: 10
data_hint: null
data_type: NIX_SYSTEM
enabled: true
tcp_address: 0.0.0.0:30000
connection_timeout_sec: 60
- syslog:
common:
batch_n_bytes: 1048576
batch_n_seconds: 10
data_hint: null
data_type: WINEVTLOG
enabled: true
tcp_address: 0.0.0.0:30001
connection_timeout_sec: 60
Filtros de expressão regular
Os filtros de expressões regulares permitem que você filtre registros com base em correspondências de expressões regulares em comparação com registros brutos.
Os filtros empregam a sintaxe RE2 descrita aqui: https://github.com/google/re2/wiki/Syntax
Os filtros precisam incluir uma expressão regular e, opcionalmente, definir um comportamento quando houver uma correspondência. O comportamento padrão em uma correspondência é de bloco (também é possível configurá-lo explicitamente como bloco).
Como alternativa, é possível especificar filtros com o comportamento allow. Se você especificar qualquer filtro de permissão, o encaminhador bloqueará todos os registros que não correspondam a pelo menos um filtro de permissão.
É possível definir um número arbitrário de filtros. Os filtros de bloco têm precedência sobre os de permissão.
Quando os filtros são definidos, eles precisam receber um nome. Os nomes dos filtros ativos serão informados ao Chronicle por meio de métricas de integridade do Forwarder. Os filtros definidos na raiz da configuração são mesclados com filtros definidos no nível do coletor. Os filtros no nível do coletor têm precedência em casos de nomes conflitantes. Se nenhum filtro for definido no nível raiz ou do coletor, o comportamento será permitir todos.
Exemplo de configuração: filtros de expressão regular
Na configuração do Forwarder a seguir, os registros WINEVTLOG que não correspondem ao
filtro raiz (allow_filter) são bloqueados. Dada a expressão regular, o filtro só permite registros com prioridades entre 0 e 99. No entanto, os registros NIX_SYSTEM que contêm "foo" ou "bar" são bloqueados, apesar de allow_filter. Isso ocorre porque os filtros usam um operador lógico "OR". Todos os registros são processados até que um filtro seja acionado.
regex_filters:
allow_filter:
regexp: ^<[1-9][0-9]?$>.*$
behavior_on_match: allow
collectors:
- syslog:
common:
regex_filters:
block_filter_1:
regexp: ^.*foo.*$
behavior_on_match: block
block_filter_2:
regexp: ^.*bar.*$
batch_n_bytes: 1048576
batch_n_seconds: 10
data_hint: null
data_type: NIX_SYSTEM
enabled: true
tcp_address: 0.0.0.0:30000
connection_timeout_sec: 60
- syslog:
common:
batch_n_bytes: 1048576
batch_n_seconds: 10
data_hint: null
data_type: WINEVTLOG
enabled: true
tcp_address: 0.0.0.0:30001
connection_timeout_sec: 60
Rótulos arbitrários
Os rótulos são usados para anexar metadados arbitrários aos registros usando pares de chave-valor. Os rótulos podem ser configurados para um encaminhador inteiro ou em um coletor específico de um encaminhador. Se ambos forem fornecidos, os rótulos serão mesclados com as chaves do coletor com precedência sobre as do encaminhador se as chaves se sobrepuserem.
Exemplo de configuração: rótulos arbitrários
Na configuração do Forwarder a seguir, os pares de chave e valor 'foo=bar' e 'meow=mix' estão anexados aos registros WINEVTLOG e a chave 'foo=baz' e 'meow=mix' e Os pares de valores são anexados aos registros NIX_SYSTEM.
metadata:
labels:
foo: bar
meow: mix
collectors:
syslog:
common:
metadata:
labels:
foo: baz
meow: mix
batch_n_bytes: 1048576
batch_n_seconds: 10
data_hint: null
data_type: NIX_SYSTEM
enabled: true
tcp_address: 0.0.0.0:30000
connection_timeout_sec: 60
syslog:
common:
batch_n_bytes: 1048576
batch_n_seconds: 10
data_hint: null
data_type: WINEVTLOG
enabled: true
tcp_address: 0.0.0.0:30001
connection_timeout_sec: 60
Namespaces
Use rótulos de namespace para identificar registros de segmentos de rede distintos e desvincular os endereços IP sobrepostos. É possível configurar um rótulo de namespace para um encaminhador inteiro ou em um coletor específico do encaminhador. Se ambos forem incluídos, o namespace do coletor específico terá precedência.
Qualquer namespace configurado para o encaminhador aparece com os recursos associados na interface do usuário do Chronicle. Também é possível pesquisar namespaces usando o recurso "Pesquisa do Chronicle".
Para informações sobre como visualizar namespaces na interface do usuário do Chronicle, clique aqui.
Exemplo de configuração: namespaces
Na configuração do Forwarder a seguir, os registros do WINEVTLOG são anexados ao namespace FORWARDER, e os registros NIX_SYSTEM são anexados ao namespace CORPORATE.
metadata:
namespace: FORWARDER
collectors:
- syslog:
common:
metadata:
namespace: CORPORATE
batch_n_bytes: 1048576
batch_n_seconds: 10
data_hint: null
data_type: NIX_SYSTEM
enabled: true
tcp_address: 0.0.0.0:30000
connection_timeout_sec: 60
- syslog:
common:
batch_n_bytes: 1048576
batch_n_seconds: 10
data_hint: null
data_type: WINEVTLOG
enabled: true
tcp_address: 0.0.0.0:30001
connection_timeout_sec: 60
Entrada do Kafka
É possível ingerir dados de tópicos do Kafka da mesma forma que para syslog. Os grupos de consumo são utilizados para permitir que você implante até três encaminhadores e extraia dados do mesmo tópico do Kafka.
Para mais informações sobre grupos de consumidores do Kafka, acesse: https://docs.confluent.io/platform/current/clients/consumer.html
Exemplo de configuração: entrada do Kafka
A configuração do Encaminhar a seguir mostra como configurá-lo para ingerir dados dos tópicos do Kafka:
collectors:
- kafka:
common:
batch_n_bytes: 1048576
batch_n_seconds: 10
data_hint: null
data_type: NIX_SYSTEM
enabled: true
username: user
password: password
topic: example-topic
group_id: chronicle-forwarder
timeout: 60
brokers:
- broker-1:9093
- broker-2:9093
tls:
insecureSkipVerify: true
certificate: "/path/to/cert.pem"
certificate_key: "/path/to/cert.key"
- syslog:
common:
batch_n_bytes: 1048576
batch_n_seconds: 10
data_hint: null
data_type: WINEVTLOG
enabled: true
tcp_address: 0.0.0.0:30001
connection_timeout_sec: 60
Balanceamento de carga e alta disponibilidade
O encaminhador do Chronicle Linux pode ser implantado em um ambiente em que um balanceador de carga da camada 4 é instalado entre a fonte de dados e as instâncias do encaminhador. Isso permite que um cliente distribua a coleta de registros por vários encaminhadores ou envie registros para um encaminhador diferente se houver falha. Esse recurso é compatível apenas com o tipo de coleção syslog.
O encaminhamento do Linux inclui um servidor HTTP integrado que responde às verificações de integridade HTTP do balanceador de carga. O servidor HTTP também ajuda a garantir que os registros não sejam perdidos durante a inicialização ou o encerramento de um encaminhador.
Configure o servidor HTTP, o balanceamento de carga e as opções de alta disponibilidade na seção server do arquivo de configuração do encaminhador. Essas opções são compatíveis com a configuração de durações de tempo limite e códigos de status retornados em resposta a verificações de integridade recebidas em implantações baseadas em programador e contêiner, bem como em balanceadores de carga tradicionais.
Use os seguintes caminhos de URL para verificações de integridade, prontidão e atividade. Os valores <host:port> são definidos na configuração do encaminhador.
- http://
<host:port>/meta/available: verificações de atividade para programadores/orquestradores de contêiner, como o Kubernetes. - http://
<host:port>/meta/ready: verificações de prontidão e verificações de integridade tradicionais do balanceador de carga
A seguinte configuração de encaminhador é um exemplo de balanceamento de carga e alta disponibilidade:
collectors:
- syslog:
common:
batch_n_bytes: 1048576
batch_n_seconds: 10
data_hint: null
data_type: NIX_SYSTEM
enabled: true
tcp_address: 0.0.0.0:30000
connection_timeout_sec: 60
- syslog:
common:
batch_n_bytes: 1048576
batch_n_seconds: 10
data_hint: null
data_type: WINEVTLOG
enabled: true
tcp_address: 0.0.0.0:30001
connection_timeout_sec: 60
server:
graceful_timeout: 15s
drain_timeout: 10s
http:
port: 8080
host: 0.0.0.0
read_timeout: 3s
read_header_timeout: 3s
write_timeout: 3s
idle_timeout: 3s
routes:
- meta:
available_status: 204
ready_status: 204
unready_status: 503
| Caminho de configuração | Descrição |
|---|---|
| server : Graceful_timeout | Quantidade de tempo em que o encaminhador retorna uma verificação de prontidão/integridade ruim e ainda aceita novas conexões. Esse também é o tempo de espera entre o recebimento de um sinal para interromper e o início do encerramento do próprio servidor. Isso permite que o balanceador de carga tenha tempo para remover o encaminhador do pool. |
| server : drenamento_tempo limite | Quantidade de tempo em que o encaminhador aguarda o fechamento bem-sucedido das conexões ativas antes de ser fechado pelo servidor. |
| server : http : port | Número da porta em que o servidor HTTP detecta verificações de integridade do balanceador de carga. O valor precisa estar entre 1024-65535. |
| server : http : host | Endereço IP ou nome do host que pode ser resolvido para endereços IP, em que o servidor precisa detectar. Se estiver vazio, o valor padrão será o sistema local (0.0.0.0). |
| server : http : read_timeout | Usado para ajustar o servidor HTTP. Normalmente, não é necessário alterar a configuração padrão. Tempo máximo permitido para ler toda a solicitação, tanto o cabeçalho quanto o corpo. É possível definir os valores read_timeout e read_header_timeout. |
| server : http : read_header_timeout | Usado para ajustar o servidor HTTP. Normalmente, não é necessário alterar a configuração padrão. Quantidade máxima de tempo permitida para ler cabeçalhos de solicitação. O prazo de leitura da conexão é redefinido depois da leitura do cabeçalho. |
| server : http : write_timeout | Usado para ajustar o servidor HTTP. Normalmente, não é necessário alterar a configuração padrão. Tempo máximo para enviar uma resposta. Ele é redefinido quando um novo cabeçalho de solicitação é lido. |
| server : http : idle_timeout | Usado para ajustar o servidor HTTP. Normalmente, não é necessário alterar a configuração padrão. Tempo máximo de espera da próxima solicitação quando as conexões inativas estão ativadas. Se o valor inatividade_inatividade é zero, o valor de read_timout é usado. Se ambos forem zero, read_header_timeout será usado. |
| routes : meta : Ready_status | Código de status que o encaminhador retorna quando está pronto para aceitar tráfego em uma das seguintes situações:
|
| routes : meta : ready_status | Código de status que o encaminhador retorna quando não está pronto para aceitar o tráfego. |
| routes : meta : available_status | Código de status que o encaminhador retorna quando uma verificação de atividade é recebida e o encaminhamento está disponível. As verificações de atividade geralmente são enviadas por programadores/orquestradores de contêiner, como o Kubernetes. |
Perguntas frequentes
O que é um contêiner do Docker?
Os contêineres do Docker, como máquinas virtuais, fornecem mais segurança, isolamento e gerenciamento de recursos.
As máquinas virtuais têm um espaço privilegiado (kernel no Linux) e um espaço do usuário (tudo que você interage com: libc, python, ls, tcpdump etc.).
Contêineres: têm apenas um espaço do usuário (tudo que você interage: libc, Python, ls, tcpdump etc.) e dependem do espaço de privilégios do host.
Por que distribuir o encaminhador do Chronicle usando um contêiner?
- Melhor segurança por meio do isolamento:
- O ambiente e os requisitos do cliente não afetam o encaminhador do Chronicle.
- O ambiente e os requisitos do encaminhador Chronicle não afetam o cliente.
- O mecanismo de distribuição de contêineres já existe e pode ser particular e separado do Google Cloud e dos clientes. https://cloud.google.com/container-registry/
Por que apenas o Linux para contêineres? E as janelas?
Os contêineres foram desenvolvidos para o Linux primeiro e estão prontos para produção.
A compatibilidade do Windows com contêineres está melhorando. Os contêineres estão disponíveis para o Windows Server 2016 e o Windows 10.
Você precisa aprender os comandos avançados do Docker?
- O encaminhador do Chronicle usa um único contêiner. Portanto, não é necessário aprender sobre o Swarm, a orquestração, o Kubernetes ou outros conceitos ou comandos avançados do Docker.