Cassandra sobre VPN: acceso separado para clientes e nodos

Un despregamento de Cassandra non ten unha única rede universal de base de datos. As aplicacións falan co servizo de cliente, os membros do clúster falan entre si e os operadores usan interfaces administrativas, e eses tres públicos non deberían herdar o alcance dos demais. Unha ruta privada como unha VPN é un bo punto de partida, pero non é a identidade de usuario da base de datos nin é a súa política de cifrado. Trate a decisión de conectividade e a decisión de autorización como dúas revisións separadas.

Cada un dos tres públicos recibe a súa propia resposta, e as seccións seguintes trátanos por orde de exposición.

Tres públicos, tres decisións

Identifique que necesita realmente cada grupo antes de tocar unha regra. Os clientes necesitan o receptor de cliente e suficiente información para chegar a cada nodo que se lles poida asignar, os nodos pares necesítanse entre si no porto entre nodos, e os operadores necesitan a interface de xestión para o que o runbook realmente esixe. Tres listas, tres públicos, tres niveis de confianza.

O erro habitual é construír un único segmento privado plano e supoñer que a fronteira da VPN fai o resto. Dentro del, unha aplicación que alcanza o porto de cliente adoita alcanzar tamén o porto entre nodos, e as ferramentas administrativas do operador a miúdo sentan no mesmo host de salto que a aplicación. Achandar todo iso xunto significa que unha identidade de aplicación comprometida xa ten máis alcance que as súas propias consultas. Debuxe os tres públicos como tres filas no documento de deseño, cada unha coa regra que a permite, e os ocos fanse visibles antes de que ninguén os constrúa.

Que necesitan os clientes, e nada máis

Permita que as fontes de aplicación previstas cheguen aos puntos finais de cliente para a versión despregada, e manteña os servizos de clúster e de xestión non relacionados fóra dese alcance. Despois comprobe como o controlador descobre os nodos. Un punto de contacto inicial accesible non demostra que cada enderezo de nodo que o controlador elixa despois sexa accesible desde ese contexto de cliente, porque o controlador pide pares ao clúster e despois conéctase aos enderezos que o clúster anuncia.

Por iso unha soa discrepancia de enderezo privado produce o patrón coñecido: unha primeira conexión correcta seguida de tempos de espera. Configure os enderezos anunciados e o encamiñamento do cliente de forma deliberada; publicar todo o clúster en internet para reparar unha discrepancia cambia un erro de encamiñamento por unha exposición que non pode recuperar.

Manteña tamén a autenticación de base de datos da aplicación e os permisos de rol. Un enderezo VPN compartido e traducido pode representar moitos usuarios ou servizos, así que nunca substitúe identidades de base de datos distintas.

Cifre por separado cliente-a-nodo e entre nodos

A documentación de seguridade de Apache trata o cifrado cliente-a-nodo e entre nodos como configuracións separadas, e activar unha non activa a outra. Esa distinción segue aplicándose dentro dunha VPN, porque o túnel protexe o seu propio segmento e non se estende automaticamente do proceso da aplicación ao proceso da base de datos nin entre cada parella de membros do clúster.

Unha configuración que activa ambos explicitamente, en lugar de herdar un valor predeterminado de modelo, parécese aproximadamente a isto:

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

En configuracións de servidor que permiten cifrado de cliente opcional, aceptar TLS pode coexistir con aceptar conexións non cifradas, así que lea a política efectiva e non a intención. Planifique os nomes de certificado, a distribución de confianza e a renovación para os puntos finais cos que cada cliente contacta realmente; substituír un nome de host por un enderezo IP cambia a comprobación de identidade do cliente, non só a súa ruta.

Manteña a administración na súa propia ruta

O tráfico entre nodos necesita o conxunto de pares permitido e a súa propia política de protección. O acceso administrativo, incluído JMX onde se use, necesita un público separado e a súa propia autenticación. Unha aplicación autorizada a emitir consultas ordinarias non necesita por iso todas as capacidades de xestión, e o contrario é peor: unha ruta administrativa exposta ao segmento de aplicacións é a ruta máis curta dun erro a unha reconstrución. Escriba eses dous públicos por separado e nomee os seus propietarios, porque adoitan ser equipos distintos cuxas regras se fusionaron por accidente.

Manteña aliñadas as regras efectivas de nube, as regras de host e a configuración do receptor. Un receptor privado aínda pode quedar exposto mediante unha tradución ou un proxy non previstos, e unha regra pública ampla pode quedar en silencio xunto a unha regra VPN estreita ata que alguén audite ambas á vez.

Onde os operadores necesiten de verdade unha ruta de xestión, déalle un propietario nomeado e unha vida útil de credenciais máis curta que a da aplicación. Iso mantén visible a delegación cando a seguinte persoa herda o clúster.

Que promete o deseño

Valide as tres promesas con roles reais e non só con probas de conectividade. Unha aplicación aprobada debería completar o seu traballo permitido e nada máis, unha fonte excluída debería fallar na entrada de cliente, e unha identidade de aplicación debería ser rexeitada nas rutas de administración reservadas. Engada a reconexión do cliente e a selección de nodo á mesma proba de despregamento, porque é aí onde aparecen os erros de descubrimento.

Remate con tres frases no documento de deseño: que clientes poden consultar, que nodos poden comunicarse e que operadores poden administrar. Estar detrás dunha VPN é información útil de topoloxía, pero non é resposta a ningunha desas tres preguntas.