austintlee
commented
1 year ago I'm very interested in opensearch-project/OpenSearch#4. Just to be clear, you are proposing that there be a way to change the default password so that the cluster never even comes up with the default "admin" password, right? I do not want there to be any moment where my cluster is exposed with a publicly known password. https://github.com/opensearch-project/security/issues/1576 only seems to suggest to make it easy to change the password after bootstrap.
dblock
The getting started experience for OpenSearch with the default security enabled distribution is not ideal. Users start with either insecure demo configurations or have to go through a lengthy manual setup process before hitting their first curl request. The client side setup required is sometimes not well documented as well (see opensearch-project/opensearch-js#621 opensearch-project/OpenSearch#1393). The proposal is around simplifying the setup process for development and production use, while also making it more secure.
Let’s dig a bit deeper into linux and docker distribution setup to understand the gaps.
linux distribution, users download the distribution, untar it and then setup security by either
For multi-node, repeat this process on all nodes.
docker distribution, users download the docker-compose.yml file and run docker-compose up. The dockerfile image comes with demo configurations pre-installed as the install_demo_configurations.sh tool configures these during image creation. The docker-compose provided only works for running multiple containers on a single node. There is no easy orchestration mechanism available for multi-node setup here as well.
There are several problems here. First, the defaults are insecure. The demo certificates (that come pre-configured in docker) provided by the install_demo_configurations.sh are inherently insecure due to their private keys being publicly visible.Along same lines, the default admin:admin password is a big vulnerability. Second, there are no guardrails to prevent using demo configurations in production. There is no intimation mechanism available after setup that lets users know if they are using insecure configurations, thus making it a vulnerability if used with critical data or carried to production. Third, there is no multi-node orchestration support available. Users need to repeat the same process on every node (and do more) to setup a multi-node cluster. Fourth, there is little troubleshooting support available in logs if users face configuration issues. There have been several occasions where users have had to reach out to seek help.
Here are some initial thoughts around making this better.
Replace install_demo_configurations.sh tool with a certificate management tool. certificate management tool can help with self-signed certificate creation and installation in OpenSearch (and eventually rotation as well). The self-signed certificates are relatively more secure than demo certs and qualify as better default. It is important that the ease of use is maintained for a quick getting started experience and to achieve that, self-signed certificate tool can work in two modes - default (use -f) and interactive (use -i). In default mode, the tool could assume default values so users can still enjoy the single click experience for quick getting started. The interactive mode (-i), on the other hand, helps users to setup the self-signed certificate in an interactive fashion with user-provided inputs. In both modes, the tool auto-configures the OpenSearch security settings based on the new certificates. Details https://github.com/opensearch-project/OpenSearch/issues/1633
Remove demo certificates from docker distribution and package the certificate management tool instead. the same certificate management tool as discussed above, could be packaged inside the docker image and used to create self-signed certificates when a container starts for the first time. Have some idea around how to do this, but validating the possibility with a PoC. Details https://github.com/opensearch-project/OpenSearch/issues/1634
Open process to only localhost if demo certificates are used. This may only be needed if for some reason we find the certificate management tool is unable to provide that single click getting experience like install_demo_configurations.sh tool does. The suggestion here is to use signatures to detect demo certificates and if found, restrict the OpenSearch process from listening on non-localhost address. This would put guardrails to prevent the demo certificate use in production. Requires poc as well.
Replace admin:admin password. The default admin password is the single most important thing that must be fixed. It is configured this way in a yml config file and automatically loads up (unless changed manually) when OpenSearch is bootstrapped. It would be best to remove such default weak passwords and prompt users instead to set them up while setting up the process. Now to make it easy for them, OpenSearch could provide a tool that auto-generates strong passwords, or configures with user input. Details https://github.com/opensearch-project/OpenSearch/issues/1650
Provide an orchestration support for multi-node security setup with kubernetes This would help cut down the repetitive configuration steps required on each node for a multi-node setup, by having an orchestration layer do it.
Provide troubleshooting support It would be nice to add some troubleshooting logs that guide users to the right fix for failures that happen during setup due to configuration issues. Example - https://github.com/opensearch-project/OpenSearch/pull/1602
Besides, as a side task, update the documentation based on the new simplified and secured out of box experience. Tracking issue - https://github.com/opensearch-project/documentation-website/issues/413
https://github.com/opensearch-project/security/issues/1626More derived tasks as part of securing the OpenSearch installation