Como conectar clientes distribuídos a um banco de dados InfluxDB privado

O InfluxDB se tornou uma maneira popular de sensores e serviços armazenarem dados de séries temporais, e o InfluxData torna isso rápido e fácil graças ao InfluxCloud. Alguns dos clientes com quem conversamos não estão armazenando tudo em um serviço de nuvem gerenciado. Às vezes, eles têm motivos comerciais, regulamentares ou de conformidade específicos para armazenar os dados em seu próprio data center. Outras vezes, eles estão usando várias saídas no Telegraf para enviar dados para o InfluxDB Cloud como parte de seu plano de recuperação de desastres.

Seja qual for o motivo, ter um único cliente conectado a um banco de dados InfluxDB privado com segurança envolve potencialmente a configuração de rotas de rede, abertura de firewalls, ajuste de NACLs e grupos de segurança. Sem mencionar a navegação em quaisquer processos internos que possam estar envolvidos para obter todas essas alterações aprovadas e implantadas. O valor do InfluxDB não é ter apenas um cliente gravando dados ocasionalmente, mas sim ser capaz de suportar centenas ou mais. Portanto, repita essa sobrecarga de administração de rede para cada novo dispositivo, ou sempre que a configuração de rede de um dispositivo for alterada, e você rapidamente terá uma situação em que manter esses controles rígidos de rede se torna insustentável. A maioria das pessoas então ponderaria entre algumas opções: 1) Exigir que uma VPN seja estabelecida entre o cliente remoto e a rede em que o banco de dados InfluxDB está. maior carga de configuração para quem está gerenciando os clientes. E eles realmente querem que a rede deles seja conectada à sua por meio de uma VPN? Ou 2) Exponha o banco de dados InfluxDB diretamente à Internet pública e confie no sistema de autenticação para protegê-lo.

Hoje vou levá-lo através de uma terceira escolha. Levará apenas alguns minutos para ser implementado, não exigirá alterações na rede e evitará que você tenha que colocar seu banco de dados privado na Internet pública. Também teremos uma série de outros benefícios lançados ao longo do caminho, que abordarei assim que começarmos a funcionar.

Configuração inicial

Se você quiser pular direto para um exemplo prático disso, temos disponível no GitHub um Demonstração InfluxDB + Telegraf + Ockam para Docker que você pode executar localmente com o Docker Compose. Ele usa as imagens oficiais do Docker para InfluxDB e Telegraf, com alterações nos scripts de inicialização para que cada serviço use o Ockam para estabelecer uma conexão. Instruções completas sobre como executá-lo estão incluídas no README .

Para simular um exemplo de ponta a ponta de um cliente enviando dados para o InfluxDB, vamos iniciar uma instância do Telegraf, fazer com que ela emita eventos de CPU para o InfluxDB e, em seguida, altere a maneira como esses dois se conectam para mostrar como os conectaríamos em diferentes hosts ou redes. Por causa deste exemplo, porém, estaremos executando tudo em uma única máquina.

Ockam

Se você já configurou o Ockam anteriormente, pode pular esta seção e ir direto para a configuração do InfluxDB abaixo.

 brew install build-trust/ockam/ockam

(se você não estiver usando o brew para gerenciamento de pacotes, temos instruções de instalação para outros sistemas em nossa documentação)

Depois de instalado, você precisa registrar sua identidade local no Ockam Orchestrator, execute o comando abaixo e siga as instruções fornecidas:

 ockam enroll

InfluxDB

Se você já tem o InfluxDB rodando em sua máquina local e tem um token de autenticação que pode usar para escrever nele, você pode pular esta seção e ir direto para a instalação do Telegraf abaixo.

Os pré-requisitos para esta seção são primeiro instalar:

• InfluxDB
• CLI de influxo

Uma vez instalado, precisamos iniciar o InfluxDB para que tenhamos um lugar para armazenar os dados de métricas que vamos gerar. Na maioria dos sistemas, isso será tão simples quanto executar:

 influxd

Você deve ver alguma saída de log, com a linha final confirmando que o influxd agora está escutando na porta 8086 :

 2023-02-21T23:49:43.106268Z info Listening {"log_id": "0fv9CURl000", "service": "tcp-listener", "transport": "http", "addr": ":8086", "port": 8086}

Se o influxd for iniciado com sucesso, você poderá abrir uma nova sessão de terminal e deixá-la em execução em segundo plano. Se o influxd não foi iniciado com sucesso, verifique o documentação oficial para alguns problemas comuns para diferentes sistemas operacionais.

Agora vamos usar o comando CLI influx para concluir a configuração inicial do banco de dados para que o influxd possa receber nossos dados. Execute o comando setup e conclua os prompts necessários, lembre-se da organização e dos nomes dos buckets que você usa, pois precisaremos deles mais tarde:

 influx setup

Em seguida, você precisará copiar o token para o usuário que acabou de criar, que pode ser recuperado com o comando auth:

 influx auth list

telégrafo

Instalar o Telegraf , e uma vez configurado, precisaremos de um arquivo de configuração que defina nossa fonte de entrada e nosso destino de saída. Felizmente, o Telegraf inclui um comando para gerar esse arquivo, que podemos especificar para ser pré-configurado com a utilização da CPU de nossa máquina host como fonte de entrada e com o InfluxDB como nossa saída.

Para gerar a configuração base execute:

 telegraf config \ --section-filter agent:inputs:outputs \ --input-filter cpu \ --output-filter influxdb_v2 > telegraf.conf

Abra o arquivo telegraf.conf gerado e localize a seção [[outputs.influxdb_v2]] que deve ficar assim:

 [[outputs.influxdb_v2]] ## The URLs of the InfluxDB cluster nodes. ## ## Multiple URLs can be specified for a single cluster, only ONE of the ## urls will be written to each interval. ## ex: urls = ["https://us-west-2-1.aws.cloud2.influxdata.com"] urls = ["http://127.0.0.1:8086"] ## Token for authentication. token = "" ## Organization is the name of the organization you wish to write to. organization = "" ## Destination bucket to write into. bucket = ""

Substitua os valores vazios de token, organização e bucket pelos valores da seção anterior sobre Configurando o InfluxDB e salvar suas alterações. Agora você pode iniciar o Telegraf:

 telegraf --config telegraf.conf

Verifique se está tudo funcionando

Para facilitar a reutilização de seus valores para comandos e testes futuros, armazene os valores apropriados (ou seja, substitua os espaços reservados abaixo por seus valores reais) em uma série de variáveis de ambiente:

 export INFLUX_PORT=8086 \ INFLUX_TOKEN=your-token-here \ INFLUX_ORG=your-org \ INFLUX_BUCKET=your-bucket

Agora podemos verificar se o Telegraf está enviando dados regularmente para o InfluxDB. A configuração que criamos anteriormente emitirá estatísticas de CPU a cada 10 segundos, para que possamos enviar uma consulta ao InfluxDB e retornar todos os dados que ele possui no último minuto:

 curl \ --header "Authorization: Token $INFLUX_TOKEN" \ --header "Accept: application/csv" \ --header 'Content-type: application/vnd.flux' \ --data "from(bucket:\"$INFLUX_BUCKET\") |> range(start:-1m)" \ http://localhost:$INFLUX_PORT/api/v2/query?org=$INFLUX_ORG

Conecte com segurança Telegraf + um InfluxDB privado com Ockam

O exemplo acima conecta esses dois serviços, em execução no mesmo host, usando o transporte HTTP não criptografado padrão. A maioria das configurações não triviais terá o InfluxDB rodando em um host separado com um ou mais nós do Telegraf enviando dados.

Nesta seção, mostraremos como esses dois problemas podem ser resolvidos com alterações mínimas na configuração de quaisquer serviços existentes.

Criando e registrando seus nós

A primeira etapa é inscrever-se no Ockam, salvar as informações do projeto e criar tokens de inscrição para os nós InfluxDB e Telegraf:

 ockam enroll ockam project information --output json > project.json export OCKAM_INFLUXDB_TOKEN=$( \ ockam project enroll --attribute component=influxdb) export OCKAM_TELEGRAF_TOKEN=$( \ ockam project enroll --attribute component=telegraf)

Agora podemos criar um nó para nosso serviço InfluxDB:

 ockam identity create influxdb ockam project authenticate --identity influxdb \ --token $OCKAM_INFLUXDB_TOKEN --project-path project.json ockam node create influxdb \ --project project.json \ --identity influxdb ockam policy set \ --at influxdb \ --resource tcp-outlet \ --expression '(= subject.component "telegraf")' ockam tcp-outlet create \ --at /node/influxdb \ --from /service/outlet \ --to 127.0.0.1:8086 ockam forwarder create influxdb \ --at /project/default \ --to /node/influxdb

Há algumas coisas que aconteceram nesses comandos, então vamos descompactá-los rapidamente:

• Criamos um novo nó chamado influxdb e o registramos no Ockam usando o token que geramos anteriormente. Se você olhar novamente para o comando que gerou o token, verá que também marcamos esse token com um atributo de component=influxdb .
• Em seguida, adicionamos uma política ao nó influxdb , que afirma que apenas os nós que possuem um atributo component com um valor de telegraf poderão se conectar a uma saída TCP.
• Em seguida, criamos uma saída TCP. Isso é como um canal do nó influxdb que acabamos de criar para a porta TCP de 127.0.0.1:8086 (ou seja, a porta em que nosso banco de dados InfluxDB está escutando). Este nó Ockam agora canalizará todos os dados que receber de outros nós para esse destino. No entanto, os únicos nós que poderão estabelecer essa conexão são aqueles que passarem pela política definida na etapa anterior.
• Por fim, criamos um encaminhador em nosso projeto, que agora permite que outros nós em nosso projeto descubram o influxdb e roteem o tráfego para ele.

Agora é hora de estabelecer o outro lado dessa conexão criando o nó cliente correspondente para o Telegraf:

 ockam identity create telegraf ockam project authenticate --identity telegraf \ --token $OCKAM_TELEGRAF_TOKEN --project-path project.json ockam node create telegraf \ --project project.json \ --identity telegraf ockam policy set \ --at telegraf \ --resource tcp-inlet \ --expression '(= subject.component "influxdb")' ockam tcp-inlet create \ --at /node/telegraf \ --from 127.0.0.1:8087 \ --to /project/default/service/forward_to_influxdb/secure/api/service/outlet

Agora podemos descompactar esses três comandos e o que eles fizeram:

• Como antes, usamos o token de inscrição que geramos para criar um novo nó e o registramos em nosso projeto. Desta vez é o nó telegraf .
• Aplicamos novamente uma política para melhorar nossa postura de segurança. Essa política permite que um inlet TCP seja criado, mas somente se o nó na outra extremidade tiver o atributo component com um valor de influxdb .
• Finalmente, criamos a entrada TCP. Esta é uma forma de definir onde o nó deve escutar as conexões (neste caso na porta TCP 8087 ), e para onde deve encaminhar esse tráfego. Esse nó encaminhará os dados para o encaminhador que criamos anteriormente, que por sua vez os passará para nosso nó influxdb, que os enviará para o banco de dados InfluxDB.

É isso! O ouvinte na porta localhost 8087 agora está encaminhando todo o tráfego para o InfluxDB, onde quer que esteja em execução. Se esse banco de dados estiver em um host diferente, em execução na nuvem ou em um data center privado, o registro e o encaminhamento ainda garantirão que nossa comunicação com 127.0.0.1:8087 seja conectada com segurança a qualquer lugar em que o banco de dados esteja sendo executado.

Atualize a configuração existente para usar a conexão segura

Este exemplo criou a entrada TCP na porta 8087 principalmente porque o serviço influxd estava sendo executado no mesmo host e já vinculado à porta 8086 . Em uma implantação de produção em que o Telegraf e o InfluxDB estão em hosts separados, a entrada TCP pode escutar na porta 8086 e essa configuração padrão não precisa ser alterada.

Embora este seja um exemplo simplificado em execução em um único host, as instruções a seguir são as mesmas, independentemente de sua implantação. Depois que os nós influxdb e telegraf estiverem registrados e em execução, a única alteração que você precisa fazer é atualizar seu telegraf.conf para apontar para a porta de escuta local:

 [[outputs.influxdb_v2]] urls = ["http://127.0.0.1:8087"]

Reinicie o serviço Telegraf e podemos verificar se ele ainda está armazenando dados usando o mesmo comando que usamos anteriormente.z

Clientes conectados com segurança e muito mais...

O exemplo aqui, em menos de 10 minutos, resolveu nosso problema mais premente, adicionando uma série de melhorias valiosas que não são imediatamente óbvias porque foram abstraídas:

• Bancos de dados privados permanecem privados: seu InfluxDB não teve sua porta exposta à Internet pública e, portanto, não há rota para terceiros

  
  

• Criptografado em trânsito: o canal seguro estabelecido entre seus nós é criptografado de ponta a ponta. Cada nó gera suas próprias chaves criptográficas e recebe suas próprias credenciais exclusivas. Eles então os usam para estabelecer um canal seguro mutuamente confiável entre si. Ao remover a dependência de um serviço de terceiros para armazenar ou distribuir chaves, você pode reduzir sua área de superfície de vulnerabilidade e eliminar pontos únicos de falha.

  
  

• Controle de acesso baseado em identidade e atributo: A autorização até mesmo para estabelecer uma rota para o banco de dados InfluxDB está vinculada à identidade exclusiva do cliente solicitando acesso, que é mais flexível em termos de suporte a abordagens de implantação modernas e frequentemente dinâmicas e também se alinha mais claramente com nossas intenções em relação ao controle de acesso. Se o cliente for capaz de estabelecer a confiança de que eles são quem dizem ser, eles poderão rotear seus pacotes para o banco de dados. Compare isso com abordagens históricas que tomam decisões de acesso permanente com base em suposições sobre a rede remota (por exemplo, esta solicitação vem de um endereço IP que pré-autorizamos?). Isso é um acréscimo aos controles de autenticação e autorização no próprio banco de dados InfluxDB, que continuarão a funcionar como sempre.

  
  

• Secure-by-design: A combinação de todos os itens acima significa que a única maneira de acessar o banco de dados InfluxDB é por meio de um canal seguro, o que significa que toda a comunicação é criptografada em trânsito, independentemente de qualquer configuração incorreta em qualquer extremidade (por exemplo, HTTP/TLS não está habilitado). E como cada nó troca credenciais entre si, em vez de compartilhar um certificado comum ou uma chave de criptografia compartilhada, você também pode ter certeza de que:

  
  

  1. Nenhuma outra parte na cadeia de abastecimento pode modificar os dados em trânsito. Os dados que você recebe no consumidor são exatamente os que foram enviados pelos seus clientes.

  2. Que apenas clientes autorizados possam gravar no InfluxDB, garantindo que os dados em seu tópico sejam altamente confiáveis. Se você tiver requisitos ainda mais rigorosos, poderá assumir o controle de sua autoridade de credencial e aplicar políticas de autorização granulares.

     
     

• Área de superfície de vulnerabilidade reduzida: Ockam simplifica as preocupações de acesso do cliente, expondo todos os serviços remotos como serviços locais. Nós chamamos isso adjacência virtual . Quando todos os componentes remotos de um aplicativo se tornam virtualmente adjacentes a todos os outros componentes, a complexidade de segurança e confiança de toda a rede, toda a infraestrutura, toda a Internet é completamente abstraída. Todos os intermediários de terceiros são removidos da superfície de vulnerabilidade do aplicativo.

Próximos passos

• Se você ainda não seguiu o exemplo deste guia, você pode começar a usar Ockam gratuitamente seguindo as instruções em nossa documentação.
• Se você gostaria de falar especificamente sobre este ou outros possíveis casos de uso para Ockam, a equipe ficaria mais do que feliz em Conversar com você .
• Como alternativa, você pode se juntar a nós e a uma comunidade cada vez maior de desenvolvedores que desejam criar confiança criando aplicativos seguros por design, no Crie um servidor Discord da comunidade de confiança ou em GithubGenericName .