javv-opensearch¶

This chart installs OpenSearch for JAVV: one node, with its security plugin on and two users with a password.

• admin: the superuser of OpenSearch.
• javv: the user that the JAVV backend signs in as.

The chart wraps the official opensearch chart 3.9.0. It sets the same values as the JAVV compose file.

The Service is javv-opensearch, https on port 9200. JAVV signs in to it as javv, with these settings (Connection to OpenSearch):

• JAVV_OPENSEARCH_URL=https://javv-opensearch:9200
• JAVV_OPENSEARCH_USERNAME=javv
• JAVV_OPENSEARCH_PASSWORD from the Secret of javv

This user has only the javv role: the indices of JAVV, their snapshots and the health of the cluster (An OpenSearch of your own).

Install¶

Prerequisites¶

• A Kubernetes cluster, and kubectl and Helm that can connect to it.
• bash and openssl. The commands read the admin password at a prompt, and make the password of javv in place. Thus neither password goes into your shell history or into the arguments of a process.
• An admin password that OpenSearch accepts:
  • 8 characters or more, with upper case, lower case, a digit and a special character.
  • Not a common password.

The passwords¶

• Each password comes from a Secret with the key password, or from a value that the chart puts in a Secret.
• The password of admin comes from opensearch.javv.auth.
• The password of javv comes from opensearch.javv.backend. Use a long random string.

Steps¶

1. Make the Secrets and install the chart:

   VERSION=0.9.6
   read -rs -p 'OpenSearch admin password: ' pw && echo
   printf '%s' "$pw" | kubectl create secret generic javv-opensearch-admin --from-file=password=/dev/stdin
   unset pw
   kubectl create secret generic javv-opensearch-backend \
     --from-file=password=<(openssl rand -hex 24 | tr -d '\n')
   helm install javv-opensearch oci://ghcr.io/danube-labs/charts/javv-opensearch --version "$VERSION" \
     --set opensearch.javv.auth.existingSecret=javv-opensearch-admin \
     --set opensearch.javv.backend.existingSecret=javv-opensearch-backend
   helm test javv-opensearch
   

2. Install the javv chart with opensearch.passwordSecret.name=javv-opensearch-backend.

Where the chart comes from¶

• Each JAVV release publishes this chart at oci://ghcr.io/danube-labs/charts, and signs it (Verify the images and charts).
• From a checkout, use the folder of the chart in deploy/helm/.

What helm test verifies¶

• OpenSearch refuses a request without a sign-in.
• admin and javv are the only users in the user list of OpenSearch.
• javv holds only the javv role, and the security API refuses it.
• OpenSearch refuses readall, one of the demo users that OpenSearch would otherwise add.
• With your own certificate, the certificate of the https endpoint is valid for your CA.

Certificates¶

• With your own certificate, the node reads a new certificate without a restart. The chart mounts the Secret as a folder, and sets plugins.security.ssl.certificates_hot_reload.enabled.
• The chart never makes a certificate itself.

Users and roles¶

• The users file of the image holds admin and six demo users whose passwords are their own names. No setting turns them off.
• An init container puts a new file in its place, with only admin and javv. It hashes each password from its Secret with hash.sh of OpenSearch, which reads the password from the environment.
• The javv role and its mapping come from the files/ folder of the chart, as in the compose file. The mapping is admin on all_access, and javv on javv. These files replace the demo files of the image.
• OpenSearch loads these files at its first start. After that, its security index holds them.

Change a password¶

A new password in the Secret alone changes nothing: OpenSearch keeps the password in its security index.

Prerequisites:

• The new password.
• For your own certificates: a client certificate that the CA in your Secret signed, with its subject in opensearch.javv.tls.adminDn, and its PKCS#8 key.

Steps:

1. Put the new password in its Secret, or in the value of the chart and run helm upgrade.
2. Restart the node. The init container then writes the users file with the new password: kubectl rollout restart statefulset/javv-opensearch-master. The old password still works.

3. Load the file into the security index with securityadmin.sh of OpenSearch. This tool signs in with an admin certificate. With the demo certificates, use the certificate of the image:

   kubectl exec javv-opensearch-master-0 -c opensearch -- \
     plugins/opensearch-security/tools/securityadmin.sh \
     -f config/opensearch-security/internal_users.yml -t internalusers -icl -nhnv \
     -cacert config/root-ca.pem -cert config/kirk.pem -key config/kirk-key.pem
   

   With your own certificates, copy your client certificate and its key into the pod with kubectl cp. Run the same command with -cacert config/certs/ca.crt -cert <the certificate> -key <its key>. Then delete the two files.

   The command ends with Done with success. From then on, the new password works and the old password does not.

4. For the password of javv, restart the JAVV backend. It then reads the new password from the same Secret. The name of the Deployment comes from the name of the javv release:

   • Release javv, as in Deploying: kubectl rollout restart deploy/javv-backend.
   • A release name that holds javv: <release>-backend.
   • Each other release name: <release>-javv-backend.

The same securityadmin.sh command loads the role file and the mapping file. Use -f config/opensearch-security/roles.yml -t roles, then -f config/opensearch-security/roles_mapping.yml -t rolesmapping. Do this for an OpenSearch that started without these files, or for a release that changes the role.

Values¶