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   InfluxDB Cloud como parte de seu plano de recuperação de desastres. o  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  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   .   Demonstração InfluxDB + Telegraf + Ockam para Docker 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  para diferentes sistemas operacionais.   documentação oficial para alguns problemas comuns  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  , 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.   Instalar o Telegraf  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   que deve ficar assim: [[outputs.influxdb_v2]]   [[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  e salvar suas alterações. Agora você pode iniciar o Telegraf:   Configurando o InfluxDB   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   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   . influxdb component=influxdb  Em seguida, adicionamos uma política ao nó   , que afirma que apenas os nós que possuem um atributo   com um valor de   poderão se conectar a uma saída TCP. influxdb component telegraf  Em seguida, criamos uma saída TCP. Isso é como um canal do nó   que acabamos de criar para a porta TCP de   (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. influxdb 127.0.0.1:8086  Por fim, criamos um encaminhador em nosso projeto, que agora permite que outros nós em nosso projeto descubram o   e roteem o tráfego para ele. influxdb  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   com um valor de   . component influxdb  Finalmente, criamos a entrada TCP. Esta é uma forma de definir onde o nó deve escutar as conexões (neste caso na porta TCP   ), 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. 8087  É isso! O ouvinte na porta localhost   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   seja conectada com segurança a qualquer lugar em que o banco de dados esteja sendo executado. 8087 127.0.0.1:8087   Atualize a configuração existente para usar a conexão segura  Este exemplo criou a entrada TCP na porta   principalmente porque o serviço influxd estava sendo executado no mesmo host e já vinculado à porta   . 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   e essa configuração padrão não precisa ser alterada. 8087 8086 8086  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   e   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: influxdb telegraf   [[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:    seu InfluxDB não teve sua porta exposta à Internet pública e, portanto, não há rota para terceiros Bancos de dados privados permanecem privados:    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. Criptografado em trânsito:    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 é   aos controles de autenticação e autorização no próprio banco de dados InfluxDB, que continuarão a funcionar como sempre. Controle de acesso baseado em identidade e atributo: um acréscimo    A combinação de todos os itens acima significa que a   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: Secure-by-design: única  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.  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.    Ockam simplifica as preocupações de acesso do cliente, expondo todos os serviços remotos como serviços locais. Nós chamamos isso  . 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. Área de superfície de vulnerabilidade reduzida:   adjacência virtual   Próximos passos  Se você ainda não seguiu o exemplo deste guia, você pode  gratuitamente seguindo as instruções em nossa documentação.   começar a usar Ockam  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  ou em  .   Crie um servidor Discord da comunidade de confiança   GithubGenericName  Publicado também   . aqui

Build Applications That Trust Data-in-Motion

Este áudio é produzido no idioma original da história!

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

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Telegram: a ponte da Crypto Island para o continente

Modelo Bitcoin UTXO, alimentando um ecossistema único

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Guia do arquiteto para construir arquitetura de referência para um Datalake de IA/ML

Telegram: a ponte da Crypto Island para o continente

Modelo Bitcoin UTXO, alimentando um ecossistema único

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Guia do arquiteto para construir arquitetura de referência para um Datalake de IA/ML

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps