Elastic ADR Update (#2791)

* - Added authentication risks

* - Remove pricing info

---------

Co-authored-by: Andrew <84722778+andrew-jameson@users.noreply.github.com>

docs/Technical-Documentation/Architecture-Decision-Record/017-elastisearch.md

@@ -35,7 +35,11 @@ We will use an Elastisearch and Kibana stack for their modern feature set and sc
    - This is mostly mitigated through a SQL Workbench provided in Kibana where you can use regular SQL syntax to query records.
  * More infrastructure to manage.
    * This is mostly mitigated due to using a Cloud.gov managed service for ES and Terraform, this greatly simplifies scaling the cluster and abstracts away a lot of the difficult cluster management tasks we would have to do if we didn't use a managed service.
-   * Additional overhead to run a proxy application to control access to ES + Kibana
+   * Additional overhead to run a proxy application to control access to ES + Kibana+
+ * Security & Authentication
+   * Cloud.gov ES service is a wrapper around AWS OpenSearch/ES. AWS ES does not support Xpack (Elastic/Kibana native security features) because it was forked off of Elastic 7.10.2 which did not support Xpack at that time. This implies that our current Xpack configuration we are using with our local Elastic 7.17.6/Kibana 7.17.10 deployments ([implemented here](https://github.com/raft-tech/TANF-app/pull/2775)) will not be applicable to our deployed environments. To get around this issue, AWS suggests introducing a [proxy EC2 node](https://aws.amazon.com/blogs/security/how-to-control-access-to-your-amazon-elasticsearch-service-domain/) to implement the same type of features that Xpack natively provides by way of IAM policies and Signature Version 4 request signing. However, Cloud.gov does not allow access to the underlying AWS resources it is wrapping, thus making this workaround impossible.
+   * Another option to workaround AWS ES and Cloud.gov would be to deploy and manage our own ES cluster to Cloud.gov in each space. This also introduces large blocks in and of itself. To deploy/manage our own cluster would take at least one dedicated Elastic SME to ensure uptime, availability, updates, security, etc... This would also imply that we would need to purchase Elastic Stack self-managed licenses from Elastic. To acquire the minimum feature set we need to have robust security and authentication integration with TDP, we would need to procure platinum tier licenses. Elastic requires a minimum of three licenses to be purchased. We at a minimum, would need three nodes per environment (9 licenses total) to have a functioning Elastic cluster. However, the cost of these licenses and the cost of at least one person to manage the cluster(s)/licenses makes this an infeasible option.
+   * With these things considered, the best security/authentication we can provide at this time (12/22/2023) is by blocking all external incoming traffic to our Elastic and Kibana servers, and by leveraging the view based auth [implemented here](https://github.com/raft-tech/TANF-app/pull/2775), which prevents non admin and non HHS AMS authenticated users from navigating to Kibana via the frontend. We will not be able to use any Xpack features (RBAC, Realms, P2P encryption, etc...) used in that PR in our deployed environments.
 
 ## Notes