Change Details

This task tracks the potential solutions to handle sensitive log producers. This requirement stems from the fact that certain categories of logs can be considered sensitive and their access should be restricted to root-level users only. Out of the box Kibana/Elasticsearch do not support properly isolated multi tenancy, thus the need to investigate possible solutions. ---- Possible Approaches: # "Stack" formerly "X-Pack" from elastic. (https://www.elastic.co/products/stack) * Pros * "Official" solution provided by Elastic which provides rbac by way of Elasticsearch and Kibana plugins (among other non-security features). * Cons * Requires an expensive paid license from elastic (see "security" https://www.elastic.co/subscriptions). * x-pack code released under "elastic license" https://www.elastic.co/products/x-pack/open # Search Guard community edition (https://search-guard.com/product/) * Pros * Adds rbac to Elasticsearch and Kibana by way of apache licensed Elasticsearch and Kibana plugins (https://github.com/floragunncom) (with enterprise upgrade offering more advanced features) * Cons * Does not natively support LDAP at free "community" tier, would need to work around this. # Implement our own basic access controls with an authenticating proxy filtering requests to/from Kibana and Elasticsearch. * Pros * "Drop-in" approach that does not require substantial reconfiguration of Elasticsearch or Kibana. * Cons * Simple URI filtering on the frontend reverse proxy could restrict results displayed by Kibana UI, but clever users could craft requests to retrieve sensitive log data without using Kibana. * An Elasticsearch filtering proxy would need to inspect/modify request bodies of many API calls, which would be fragile and difficult to maintain/troubleshoot. * Separate Kibana config indices are needed (one per role), requiring a mechanism to sync visualizations/dashboards/etc. between instances. # Dedicated Elasticsearch cluster and Kibana instance for sensitive log data * Pros * Simple approach from a tooling perspective, effectively duplicating existing architecture and adding output rules to route logs to the appropriate cluster. * Cons * Duplicates infrastructure maintenance overhead * Separate Kibana config indices are needed (one per role), requiring a mechanism to sync visualizations/dashboards/etc. between instances.

This task tracks the potential solutions to handle sensitive log producers. This requirement stems from the fact that certain categories of logs can be considered sensitive and their access should be restricted to root-level users only. Out of the box Kibana/Elasticsearch do not support properly isolated multi tenancy, thus the need to investigate possible solutions. ---- Possible Approaches: # "Stack" formerly "X-Pack" from elastic. (https://www.elastic.co/products/stack) * Pros * "Official" solution provided by Elastic which provides rbac by way of Elasticsearch and Kibana plugins (among other non-security features). * Cons * Requires an expensive paid license from elastic (see "security" https://www.elastic.co/subscriptions). * x-pack code released under "elastic license" https://www.elastic.co/products/x-pack/open * Adds some complexity to the Kibana and Elasticsearch deployment in that plugins and dependencies must to be installed/configured. # Search Guard community edition (https://search-guard.com/product/) * Pros * Adds rbac to Elasticsearch and Kibana by way of apache licensed Elasticsearch and Kibana plugins (https://github.com/floragunncom) (with enterprise upgrade offering more advanced features) * Cons * Does not natively support LDAP at free "community" tier, would need to work around this. * Adds some complexity to the Kibana and Elasticsearch deployment in that plugins and dependencies must to be installed/configured. # Implement our own basic access controls with an authenticating proxy filtering requests to/from Kibana and Elasticsearch. * Pros * "Drop-in" approach that does not require substantial reconfiguration of Elasticsearch or Kibana. * Cons * Simple URI filtering on the frontend reverse proxy could restrict results displayed by Kibana UI, but clever users could craft requests to retrieve sensitive log data without using Kibana. * An Elasticsearch filtering proxy would need to inspect/modify request bodies of many API calls, which would be fragile and difficult to maintain/troubleshoot. * Separate Kibana config indices are needed (one per role), requiring a mechanism to sync visualizations/dashboards/etc. between instances. # Dedicated Elasticsearch cluster and Kibana instance for sensitive log data * Pros * Simple approach from a tooling perspective, effectively duplicating existing architecture and adding output rules to route logs to the appropriate cluster. * Cons * Duplicates infrastructure maintenance overhead * Separate Kibana config indices are needed (one per role), requiring a mechanism to sync visualizations/dashboards/etc. between instances.

This task tracks the potential solutions to handle sensitive log producers. This requirement stems from the fact that certain categories of logs can be considered sensitive and their access should be restricted to root-level users only. Out of the box Kibana/Elasticsearch do not support properly isolated multi tenancy, thus the need to investigate possible solutions. ---- Possible Approaches: # "Stack" formerly "X-Pack" from elastic. (https://www.elastic.co/products/stack) * Pros * "Official" solution provided by Elastic which provides rbac by way of Elasticsearch and Kibana plugins (among other non-security features). * Cons * Requires an expensive paid license from elastic (see "security" https://www.elastic.co/subscriptions). * x-pack code released under "elastic license" https://www.elastic.co/products/x-pack/open * Adds some complexity to the Kibana and Elasticsearch deployment in that plugins and dependencies must to be installed/configured. # Search Guard community edition (https://search-guard.com/product/) * Pros * Adds rbac to Elasticsearch and Kibana by way of apache licensed Elasticsearch and Kibana plugins (https://github.com/floragunncom) (with enterprise upgrade offering more advanced features) * Cons * Does not natively support LDAP at free "community" tier, would need to work around this. * Adds some complexity to the Kibana and Elasticsearch deployment in that plugins and dependencies must to be installed/configured. # Implement our own basic access controls with an authenticating proxy filtering requests to/from Kibana and Elasticsearch. * Pros * "Drop-in" approach that does not require substantial reconfiguration of Elasticsearch or Kibana. * Cons * Simple URI filtering on the frontend reverse proxy could restrict results displayed by Kibana UI, but clever users could craft requests to retrieve sensitive log data without using Kibana. * An Elasticsearch filtering proxy would need to inspect/modify request bodies of many API calls, which would be fragile and difficult to maintain/troubleshoot. * Separate Kibana config indices are needed (one per role), requiring a mechanism to sync visualizations/dashboards/etc. between instances. # Dedicated Elasticsearch cluster and Kibana instance for sensitive log data * Pros * Simple approach from a tooling perspective, effectively duplicating existing architecture and adding output rules to route logs to the appropriate cluster. * Cons * Duplicates infrastructure maintenance overhead * Separate Kibana config indices are needed (one per role), requiring a mechanism to sync visualizations/dashboards/etc. between instances.