search

AgID / wai-infrastructure

Infrastructure code for Web Analytics Italia
https://webanalytics.italia.it
BSD 3-Clause "New" or "Revised" License
5 stars 1 forks source link

Verificare autenticazione dei componenti dello stack ElasticSearch #45

Closed pdavide closed 4 years ago

pdavide commented 5 years ago

Ove possibile dovrebbero essere impostati opportuni sistemi di autenticazione, senza lasciare componenti accessibili pubblicamente.

giafar commented 5 years ago

Per Elasticsearch quello che possiamo fare è utilizzare la componente ReadonlyREST che in versione OSS ci garantisce l'accesso agli indici di Elastic tramite varie policy ma non supporta l'autenticazione su Kibana per la quale, se vuoi, possiamo utilizzare un reverse proxy apache\nginx con Basic Authentication

pdavide commented 5 years ago

ReadonlyREST mi sembra un po' troppo, pensavo solo di rendere sicure le comunicazioni in backend tra beats ed elasticsearch:

Per quanto riguarda Kibana, mi sembra che sia necessaria un'utenza di backend e poi per l'accesso ai vari indici usa l'utenza user (già impostata in elasticsearch) => https://www.elastic.co/guide/en/kibana/6.6/using-kibana-with-security.html

Per quanto riguarda invece l'accesso esterno imposterei:

giafar commented 5 years ago

X-Pack è una feature a pagamento quindi non attivabile in versione OSS ed una delle prime cose che dà è appunto la security => https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-xpack.html Readonly REST ci da la possibilità di mettere in sicurezza tutti gli indici secondo le politiche che hai indicato ma non possiamo utilizzare utente e password per accedere a Kibana se non con il "trucco" di un reverse proxy con Basic Authentication. Ad esempio via ReadonlyREST

readonlyrest:
  access_control_rules:
    - name: "Intracluster"
      type: allow
      hosts: ["172.17.204.69/32", "172.17.204.70/32", "172.17.204.71/32"]
    - name: "Kibana"
      type: allow
      hosts: ["172.17.204.68/32"]
    - name: "Metricbeat"
      type: allow
      indices: ["metricbeat-*"]
pdavide commented 5 years ago

Good news! https://www.elastic.co/products/x-pack/open

giafar commented 5 years ago

Good news! https://www.elastic.co/products/x-pack/open

Non è tutto oro quello che luccica ... Il repo è open ma non tutte le feature sono gratis: https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-security.html#configuring-security

pdavide commented 5 years ago

Bad news. Usiamo allora ReadonlyREST! Per autenticazione Kibana possiamo adottare la soluzione reverse proxy con basicAuth over https che proponi.

pdavide commented 5 years ago

https://docs.search-guard.com/latest/search-guard-community-edition

pdavide commented 5 years ago

Include aggiornamento alla versione 7.x.

pdavide commented 4 years ago

@Valair possiamo considerare chiusa questa issue anche lato portale (https://github.com/pdavide/wai-portal/commit/e4abf7eddeeda50c416c299949068ef2cef827a1)?

Valair commented 4 years ago

@pdavide l'ho lasciata in sospeso perché non ho fatto test in dev, ma parlando con @giafar dovrebbe essere sufficiente fare basic authentication quindi dovrebbe essere ok

pdavide commented 4 years ago

Ok allora chiudiamo qui in favore di una prossima PR lato portale.

giafar commented 4 years ago

@pdavide Per gestire il tls lato elastic sto predisponendo una seconda Root CA, AGID - Web Analytics Italia - Infrastructure Root CA, che crea e firma i certificati di tutte le macchine, ogni certificato avrà come CN l'hostname e come subject alternative name l'ip. In questo modo associo i certificati ai nodi di Elastic e faccio in modo che la root ca sia trustata da tutti i nodi. Lato pod potremmo predisporre un ca bundle ed agganciarlo in modo da eseguire il trust senza dover "disabilitare" host verifier e self signed.

Non appena è pronta la eseguo direttamente su SPC-1.

pdavide commented 4 years ago

Ok perfetto. In generale sarebbe possibile avere un'unica Root CA per tutti gli usi (K8S, OpenVPN e ES) oppure ci sono elementi che impediscono o rendono sconsigliabile questa unificazione? L'idea sarebbe quella di avere un unico punto centrale di "mantenimento" del sistema di certificati, anche se magari è necessario usare tool differenti a seconda dell'applicativo.

giafar commented 4 years ago

Capisco l'osservazione ma posso unificare in modo semplice quella di OpenVPN ed ES, mentre quella del cluster k8s è gestita da Kubespray sia per la parte di k8s che etcd.

pdavide commented 4 years ago

Ok mi sembra già un ottimo risultato unificare OpenVPN ed ES.

giafar commented 4 years ago

Ok mi sembra già un ottimo risultato unificare OpenVPN ed ES.

A questo punto metto anche heketi sotto ssl

pdavide commented 4 years ago

Heketi ha qualche forma di autenticazione?

giafar commented 4 years ago

Heketi ha qualche forma di autenticazione?

Si già configurata

pdavide commented 4 years ago

@giafar qui possiamo chiudere?

giafar commented 4 years ago

@giafar qui possiamo chiudere?

Si, configurata, testata e deployata.