Change Details

[[ https://github.com/opensearch-project/opensearch-k8s-operator/blob/main/docs/userguide/main.md#user-and-role-management | The OpenSearch cluster helm chart we use offers 2 ways to do user management: OpenSearch native, or Kubernetes native ]]. We are currently using OpenSearch user management because it was a shorter learning curve for yours truly. However, it would be better to do things the Kubernetes-native way as possible, as far more people are familiar with Kubernetes than with OpenSearch. As we migrate to the 2.8 version of the chart and test the OpenSearch Operator 3.0, we should attempt to use the Kubernetes-native approach. Creating this ticket to: [] Explore the Kubernetes native approach to role and user management. [] Verify it can meet our needs (for example, creating an admin user that auths via mTLS). [] If it can, switch to the Kubernetes-native approach when we deploy the 2.8 version of the chart.

[[ https://github.com/opensearch-project/opensearch-k8s-operator/blob/main/docs/userguide/main.md#user-and-role-management | The OpenSearch cluster helm chart we use offers 2 ways to do user management: OpenSearch native, or Kubernetes native ]]. We are currently using OpenSearch user management because it was a shorter learning curve for yours truly. However, it would be better to do things the Kubernetes-native way if possible, as far more people are familiar with Kubernetes than with OpenSearch. As we migrate to the 2.8 version of the chart and test the OpenSearch Operator 3.0, we should attempt to use the Kubernetes-native approach. Creating this ticket to: [] Explore the Kubernetes native approach to role and user management. [] Verify it can meet our needs (for example, creating an admin user that auths via mTLS). [] If it can, switch to the Kubernetes-native approach when we deploy the 2.8 version of the chart.

[[ https://github.com/opensearch-project/opensearch-k8s-operator/blob/main/docs/userguide/main.md#user-and-role-management | The OpenSearch cluster helm chart we use offers 2 ways to do user management: OpenSearch native, or Kubernetes native ]]. We are currently using OpenSearch user management because it was a shorter learning curve for yours truly. However, it would be better to do things the Kubernetes-native way asif possible, as far more people are familiar with Kubernetes than with OpenSearch. As we migrate to the 2.8 version of the chart and test the OpenSearch Operator 3.0, we should attempt to use the Kubernetes-native approach. Creating this ticket to: [] Explore the Kubernetes native approach to role and user management. [] Verify it can meet our needs (for example, creating an admin user that auths via mTLS). [] If it can, switch to the Kubernetes-native approach when we deploy the 2.8 version of the chart.