Elasticsearch SSO Implementation

Modis implemented Amazon Elasticsearch managed service in conjunction with a number of other AWS services for log ingestion. To provide a Single Sign On capability, AWS SSO and Fine-grained Access Control with SAML Authentication was implemented in Amazon Elasticsearch. This solution uses existing Active Directory groups and maps those to fine grained permissions in the Elasticsearch domain.

The architecture is illustrated as follows:

In AWS SSO, Applications for Kibana are configured per environment and the SAML metadata for these applications are exported and stored in Secrets Manger for use during deployment. The steps are somewhat manual due to the limited functionality available in the CLI for the AWS SSO service.

The Applications are configured using the Idp-initiated URLs for each Elasticsearch domain, which allows the SSO landing page to be used as the point of entry for users.

A specific set of mappings are defined to enable username, email address and Active Directory groups to be included in the SAML assertion.

The Elasticsearch domain has VPC access enabled and is therefore only accessible from within the VPC and over Direct Connect. As such there is less emphasis on the Access Policy, which is permissive, with the focus instead on the use of Fine-Grained Access control and SAML authentication. SAML authentication imports the metadata from AWS SSO and the backend roles are mapped from an attribute in the SAML assertion:

The roles in AWS SSO are mapped as “backend roles” for the required Elasticsearch roles:

Configuration of authentication in the Elasticsearch domain is done using the REST API, as are Tenants, visualizations, dashboards and the roles and permission that enable users to access them. Once of the principles of the solution was to automate as much of deployment as possible and security is no exception.

It is worthwhile noting that a current limitation using AWS SSO is that the groups mapped through as part of the SAML assertion is a UUID, rather than a named group. While this does not impact functionality, the use of ids is not as clean as a named role. As the AWS SSO managed service matures, there is an expectation that this will change, and the solution will be refined.