User:BKing (WMF)/Notes/OpenSearch-on-K8s-Security-Plugin
Brian's notes on the OpenSearch security plugin (mostly about RBAC)
Files that influence RBAC behavior
Debian Package
$ dpkg -L opensearch | grep security | grep yml
/etc/opensearch/opensearch-security/action_groups.yml
/etc/opensearch/opensearch-security/allowlist.yml
/etc/opensearch/opensearch-security/audit.yml
/etc/opensearch/opensearch-security/config.yml
/etc/opensearch/opensearch-security/internal_users.yml
/etc/opensearch/opensearch-security/nodes_dn.yml
/etc/opensearch/opensearch-security/opensearch.yml.example
/etc/opensearch/opensearch-security/roles.yml
/etc/opensearch/opensearch-security/roles_mapping.yml
/etc/opensearch/opensearch-security/tenants.yml
/etc/opensearch/opensearch-security/whitelist.yml
Kubernetes
The same files exist in the OpenSearch containers we run in Kubernetes, but they are rendered by the helm chart into Kubernetes secrets
OK, so what is the source of truth for security settings?
The source of truth is the OpenSearch Security API. So if you really want to be sure that your changes are active, you'll need to make an API call.
Example Request/Response
curl -s -u ${AD} -XGET https://opensearch-ipoid-test.discovery.wmnet:30443/_plugins/_security/api/roles?pretty
| Response |
|---|
{
"kibana_server" : {
"reserved" : true,
"hidden" : false,
"description" : "Provide the minimum permissions for the Kibana server",
"cluster_permissions" : [
"cluster_monitor",
"cluster_composite_ops",
"manage_point_in_time",
"indices:admin/template*",
"indices:admin/index_template*",
"indices:data/read/scroll*"
],
"index_permissions" : [
{
"index_patterns" : [
".kibana",
".opensearch_dashboards"
],
"fls" : [ ],
"masked_fields" : [ ],
"allowed_actions" : [
"indices_all"
]
},
{
"index_patterns" : [
".kibana-6",
".opensearch_dashboards-6"
],
"fls" : [ ],
"masked_fields" : [ ],
"allowed_actions" : [
"indices_all"
]
},
{
"index_patterns" : [
".kibana_*",
".opensearch_dashboards_*"
],
"fls" : [ ],
"masked_fields" : [ ],
"allowed_actions" : [
"indices_all"
]
},
{
"index_patterns" : [
".tasks"
],
"fls" : [ ],
"masked_fields" : [ ],
"allowed_actions" : [
"indices_all"
]
},
{
"index_patterns" : [
".management-beats*"
],
"fls" : [ ],
"masked_fields" : [ ],
"allowed_actions" : [
"indices_all"
]
},
{
"index_patterns" : [
"*"
],
"fls" : [ ],
"masked_fields" : [ ],
"allowed_actions" : [
"indices:admin/aliases*"
]
}
],
"tenant_permissions" : [ ],
"static" : true
},
"readall" : {
"reserved" : true,
"hidden" : false,
"description" : "Provide the minimum permissions for to readall indices",
"cluster_permissions" : [
"cluster_composite_ops_ro"
],
"index_permissions" : [
{
"index_patterns" : [
"*"
],
"fls" : [ ],
"masked_fields" : [ ],
"allowed_actions" : [
"read"
]
}
],
"tenant_permissions" : [ ],
"static" : true
}
}
|
So how do we get from config files/k8s secrets to active security config?
Kubernetes
After an update to the Kubernetes secret, the OpenSearch operator is supposed to detect the changes and apply them via a pod called ${k8s-svc}-securityconfig-update-${random_chars}. As of this writing, I've noticed that the operator doesn't always notice changes. Deleting a pod is a sure way to get the security updates to run, but you should be very careful about doing that in production. And speaking of production, we will hopefully have a better solution for user management soon after going to production.
Adding a user with basic auth (under construction)
1. Create a password and hash it using bcrypt. Example command:
htpasswd -nBC 10 opensearch-wmf
New password:
Re-type new password:
opensearch-wmf:$2y$10$wzj0fiP9wvcK6L4iqfBKf.cUWKOxxgryqlByPIZw74zDdHw4FdZAy
2. Add the user's password and password hash to puppet secrets. 3. Update within `secret.yaml`, update `internal_users.yml` with something similar to
test_user:
hash: {{ required "Set .Values.config.private.hashed_password" .Values.config.private.hashed_password | quote }}
reserved: true
description: "For testing securityadmin operator automation"
4.