7.11.0 Detections need permissions

Hi All,

I'm using docker-compose to deploy 5 elastic nodes and 1 kibana. I followed the guide here:

Additionally, I have set the following fields:

xpack.encryptedSavedObjects.encryptionKey:
xpack.reporting.encryptionKey:
xpack.security.encryptionKey:

I've seen a couple guides for troubleshooting the detection tab but I don't see how to troubleshoot the results. I created a role with 'all' Kibana permissions and assigned this role along with Superuser to a test account. I still receive the error:

"Let’s set up your detection engine
To use the detection engine, a user with the required cluster and index privileges must first access this page. You need permissions for the signals index. For more help, contact your Elastic Stack administrator."

The results of looking into the network console as the tab loads looks like the following:

{listItems: {username: "user", has_all_requested: false,…},…}
is_authenticated: true
listItems: {username: "user", has_all_requested: false,…}
application: {}
cluster: {monitor_ml: true, manage_ccr: true, manage_index_templates: true, monitor_watcher: true,…}
all: true
create_snapshot: true
manage: true
manage_api_key: true
manage_ccr: true
manage_ilm: true
manage_index_templates: true
manage_ingest_pipelines: true
manage_ml: true
manage_own_api_key: false
manage_pipeline: true
manage_rollup: true
manage_saml: true
manage_security: true
manage_token: true
manage_transform: true
manage_watcher: true
monitor: true
monitor_ml: true
monitor_rollup: true
monitor_transform: true
monitor_watcher: true
read_ccr: true
read_ilm: true
transport_client: true
has_all_requested: false
index: {,…}
.items-default: {all: true, manage_ilm: true, read: true, create_index: true, read_cross_cluster: true, index: true,…}
all: true
create: true
create_doc: true
create_index: true
delete: true
delete_index: true
index: true
maintenance: true
manage: true
manage_follow_index: true
manage_ilm: true
manage_leader_index: true
monitor: true
read: true
read_cross_cluster: true
view_index_metadata: true
write: true
username: "user"
lists: {username: "user", has_all_requested: false,…}
application: {}
cluster: {monitor_ml: true, manage_ccr: true, manage_index_templates: true, monitor_watcher: true,…}
all: true
create_snapshot: true
manage: true
manage_api_key: true
manage_ccr: true
manage_ilm: true
manage_index_templates: true
manage_ingest_pipelines: true
manage_ml: true
manage_own_api_key: false
manage_pipeline: true
manage_rollup: true
manage_saml: true
manage_security: true
manage_token: true
manage_transform: true
manage_watcher: true
monitor: true
monitor_ml: true
monitor_rollup: true
monitor_transform: true
monitor_watcher: true
read_ccr: true
read_ilm: true
transport_client: true
has_all_requested: false
index: {,…}
.lists-default: {all: true, manage_ilm: true, read: true, create_index: true, read_cross_cluster: true, index: true,…}
all: true
create: true
create_doc: true
create_index: true
delete: true
delete_index: true
index: true
maintenance: true
manage: true
manage_follow_index: true
manage_ilm: true
manage_leader_index: true
monitor: true
read: true
read_cross_cluster: true
view_index_metadata: true
write: true
username: "user"

I appreciate any help.

Thank you

This is a bug in 7.11 and earlier that means that checks for the "manage_own_api_key" privilege don't work correctly for superusers. This should be fixed in an upcoming release.

You might be able to workaround it by explicitly giving your test role the manage_own_api_key cluster privilege.

Note: In the context, I cannot tell if that is the problem that is preventing detections from working, but it is the only privilege that is failing, so it's a place to start.

I added the manage_own_api_key role to the test user and that did not resolve; however, I now see has_encryption_key: false in the network/privileges. My yml had xpack.encryptedSavedObjects.encryptionKey: "blahblah32characters" but i changed it to:
xpack.encryptedSavedObjects:
encryptionKey: "min-32-byte-long-strong-encryption-key"
which initially didn't work. I had to change it to encryptionKey="min-32-byte-long-strong-encryption-key"

Are there other bugs that prevent the detection tab from working? Would supplying my docker-compose.yml assist in troubleshooting?

I heard this issue was resolved in 7.12 so I upgraded to 7.12 and the issue appears to have changed. I now see:
has_all_requested: true
has_encryption_key: false

Kibana portion of elastic-tls.yml below:

version: '2.2'

services:

kib01:
image: docker.elastic.co/kibana/kibana:${VERSION}
container_name: kib01
depends_on: {"es01": {"condition": "service_healthy"}}
ports:
- 5601:5601
environment:
SERVERNAME: localhost
ELASTICSEARCH_URL: https://es01:9200
ELASTICSEARCH_HOSTS: https://es01:9200
ELASTICSEARCH_USERNAME: kibana_system
ELASTICSEARCH_PASSWORD: somepasswordhere
ELASTICSEARCH_SSL_CERTIFICATEAUTHORITIES: $CERTS_DIR/ca/ca.crt
SERVER_SSL_ENABLED: "true"
SERVER_SSL_KEY: $CERTS_DIR/kib01/kib01.key
SERVER_SSL_CERTIFICATE: $CERTS_DIR/kib01/kib01.crt
xpack.encryptedSavedObjects.encryptionKey: 20de42e4b74b01683d66b4756edb07e8
xpack.reporting.encryptionKey: e652913ef7d80e4090b5f445dc367870
xpack.security.encryptionKey: 57af661b4ae43198e5df07378da02c76
volumes:
- certs:$CERTS_DIR
networks:
- elastic
volumes:
data01:
driver: local
data02:
driver: local
data03:
driver: local
certs:
driver: local

networks:
elastic:
driver: bridge

Hi @mlove, thanks for trying out Security Detections! I don't know if you've seen our "Detections requirements and prerequisites" page, but it details some of the permission configurations that are required for Detections to function correctly. From the payload in your network tab, what are the values under "index"?:

index: {,…}

Also what does the Stack Management -> Roles -> <role> look like for your role?

I see this under "index"

  1. index: {,…}

  2. .siem-signals-default: {all: true, manage_ilm: true, read: true, create_index: true, read_cross_cluster: true, index: true,…}

1. all: true
2. create: true
3. create_doc: true
4. create_index: true
5. delete: true
6. delete_index: true
7. index: true
8. maintenance: true
9. manage: true
10. manage_follow_index: true
11. manage_ilm: true
12. manage_leader_index: true
13. monitor: true
14. read: true
15. read_cross_cluster: true
16. view_index_metadata: true
17. write: true

The user has several roles assigned.

Cluster:
Manage_own_api_key, manage_api_key, superuser, machine_learning_admin, machine_learning_user

Indices
.siem-signals-*, .lists-*, and .items-*
manage, write, read, and view_index_metadata

Kibana:

  • All Spaces All privileges

That fact that has_encryption_key is false tells me that savedObject encryption might not be configured correctly. Could you please check that your elasticsearch.yml has the following setting?

xpack.security.enabled: true

Would supplying my docker-compose.yml assist in troubleshooting?

Yes, I think seeing the docker-compose.yml might help us find the potential issue

Cluster:
Manage_own_api_key, manage_api_key, superuser, machine_learning_admin, machine_learning_user

Could we try assigning only superuser role to the test user initially. This role should be sufficient in 7.12 for Detections to function properly. After we find the problem that's preventing the Detections page from working properly we can work on creating a more tailored role.

Should the default elastic user be sufficient to get detections to function properly? yml below.

version: '2.2'

services:
es01:
image: docker.elastic.co/elasticsearch/elasticsearch:${VERSION}
container_name: es01
environment:
- node.name=es01
- cluster.name=es-docker-cluster
- discovery.seed_hosts=es02,es03
- cluster.initial_master_nodes=es01,es02,es03
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
- xpack.license.self_generated.type=trial
- xpack.security.enabled=true
- xpack.security.http.ssl.enabled=true
- xpack.security.http.ssl.key=$CERTS_DIR/es01/es01.key
- xpack.security.http.ssl.certificate_authorities=$CERTS_DIR/ca/ca.crt
- xpack.security.http.ssl.certificate=$CERTS_DIR/es01/es01.crt
- xpack.security.transport.ssl.enabled=true
- xpack.security.transport.ssl.verification_mode=certificate
- xpack.security.transport.ssl.certificate_authorities=$CERTS_DIR/ca/ca.crt
- xpack.security.transport.ssl.certificate=$CERTS_DIR/es01/es01.crt
- xpack.security.transport.ssl.key=$CERTS_DIR/es01/es01.key
ulimits:
memlock:
soft: -1
hard: -1
volumes:
- data01:/usr/share/elasticsearch/data
- certs:$CERTS_DIR
ports:
- 9200:9200
networks:
- elastic

healthcheck:
  test: curl --cacert $CERTS_DIR/ca/ca.crt -s https://localhost:9200 >/dev/null; if [[ $$? == 52 ]]; then echo 0; else echo 1; fi
  interval: 30s
  timeout: 10s
  retries: 5

es02:
image: docker.elastic.co/elasticsearch/elasticsearch:${VERSION}
container_name: es02
environment:
- node.name=es02
- cluster.name=es-docker-cluster
- discovery.seed_hosts=es01,es03
- cluster.initial_master_nodes=es01,es02,es03
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
- xpack.license.self_generated.type=trial
- xpack.security.enabled=true
- xpack.security.http.ssl.enabled=true
- xpack.security.http.ssl.key=$CERTS_DIR/es02/es02.key
- xpack.security.http.ssl.certificate_authorities=$CERTS_DIR/ca/ca.crt
- xpack.security.http.ssl.certificate=$CERTS_DIR/es02/es02.crt
- xpack.security.transport.ssl.enabled=true
- xpack.security.transport.ssl.verification_mode=certificate
- xpack.security.transport.ssl.certificate_authorities=$CERTS_DIR/ca/ca.crt
- xpack.security.transport.ssl.certificate=$CERTS_DIR/es02/es02.crt
- xpack.security.transport.ssl.key=$CERTS_DIR/es02/es02.key
ulimits:
memlock:
soft: -1
hard: -1
volumes:
- data02:/usr/share/elasticsearch/data
- certs:$CERTS_DIR
networks:
- elastic

es03:
image: docker.elastic.co/elasticsearch/elasticsearch:${VERSION}
container_name: es03
environment:
- node.name=es03
- cluster.name=es-docker-cluster
- discovery.seed_hosts=es01,es02
- cluster.initial_master_nodes=es01,es02,es03
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
- xpack.license.self_generated.type=trial
- xpack.security.enabled=true
- xpack.security.http.ssl.enabled=true
- xpack.security.http.ssl.key=$CERTS_DIR/es03/es03.key
- xpack.security.http.ssl.certificate_authorities=$CERTS_DIR/ca/ca.crt
- xpack.security.http.ssl.certificate=$CERTS_DIR/es03/es03.crt
- xpack.security.transport.ssl.enabled=true
- xpack.security.transport.ssl.verification_mode=certificate
- xpack.security.transport.ssl.certificate_authorities=$CERTS_DIR/ca/ca.crt
- xpack.security.transport.ssl.certificate=$CERTS_DIR/es03/es03.crt
- xpack.security.transport.ssl.key=$CERTS_DIR/es03/es03.key
ulimits:
memlock:
soft: -1
hard: -1
volumes:
- data03:/usr/share/elasticsearch/data
- certs:CERTS_DIR networks: - elastic kib01: image: docker.elastic.co/kibana/kibana:{VERSION}
container_name: kib01
depends_on: {"es01": {"condition": "service_healthy"}}
ports:
- 5601:5601
environment:
SERVERNAME: localhost
ELASTICSEARCH_URL: https://es01:9200
ELASTICSEARCH_HOSTS: https://es01:9200
ELASTICSEARCH_USERNAME: kibana_system
ELASTICSEARCH_PASSWORD: uIezwifrARvMOWe8VIyu
ELASTICSEARCH_SSL_CERTIFICATEAUTHORITIES: $CERTS_DIR/ca/ca.crt
SERVER_SSL_ENABLED: "true"
SERVER_SSL_KEY: $CERTS_DIR/kib01/kib01.key
SERVER_SSL_CERTIFICATE: $CERTS_DIR/kib01/kib01.crt
xpack.encryptedSavedObjects.encryptionKey: aea5dca966129a3f874e5f0de6aef4d8
xpack.reporting.encryptionKey: 9385495746e2846bcddf94ec3c451ddf
xpack.security.encryptionKey: dfabcad10986e1250e347c2252687cd5
volumes:
- certs:$CERTS_DIR
networks:
- elastic
volumes:
data01:
driver: local
data02:
driver: local
data03:
driver: local
certs:
driver: local

networks:
elastic:
driver: bridge

You can double check in Stack Management -> Roles -> elastic but I believe the elastic user is assigned the superuser role, which has all the necessary permissions for the Detections page.

Could you please check in you browser dev tools Network tab what the response payload is for the following API call when you load the Detections page?

GET /api/detection_engine/index

Also is this your latest configuration for xpack.encryptedSavedObjects.encryptionKey? If so, could you try changing the value to a string?

xpack.encryptedSavedObjects.encryptionKey: 20de42e4b74b01683d66b4756edb07e8

Elastic has superuser role. I've tried with elastic in addition to a custom user with superuser role. I changed the xpack.encryptedSavedObjects.encryptionKey to a string before checking the GET /api/detection_engine/index response.

browser dev tools Network tab response payload for GET /api/detection_engine/index is below

HTTP/1.1 404 Not Found content-type: application/json; charset=utf-8 kbn-name: kibana kbn-license-sig: 9ff13504209573ae7a252ae74f4ebbab9f61c125901549c78d55d47f7d040bbb cache-control: private, no-cache, no-store, must-revalidate content-length: 67 Date: Thu, 25 Mar 2021 22:27:56 GMT Connection: keep-alive Keep-Alive: timeout=120

To further investigate, could you please enable verbose logging in your kibana instance and share the logs with us? You can enable verbose logging by adding this setting to your kibana.yml:

logging.verbose: true

logging.verbose: true gives services.kib01.environment.logging.verbose contains true, which is an invalid type, it should be a string, number, or a null

Changing it to logging.verbose: true to logging.verbose: 1 let the cluster start. Is this a valid value? Additionally, do I need to specify a directory for the logs?

Adding xpack.encryptedSavedObjects.encryptionKey into the kibana.yml in the container has made the detection tab work properly. Should this work from the docker-compose yml I posted above?

Adding xpack.encryptedSavedObjects.encryptionKey into the kibana.yml in the container has made the detection tab work properly.

This tells me that the docker-compose file is not generating the correct Kibana settings. There are a couple of ways to configure Kibana and elasticsearch with docker-compose. The traditional way according to our docs is to provide kibana.yml and elasticsearch.yml configuration files. The way the current docker-compose file is written, it's trying to configure Kibana and elasticsearch settings via environment variables. The problem I see with the current approach is that we might be mixing syntax. The syntax used for environment variables is different from the syntax used for kibana.yml and elasticsearch.yml configuration files. You can read more about the syntax differences here.

I think the mixed syntax is affecting the final configuration. So my recommendation would be to go with the traditional approach and have the docker-compose file configure Kibana and elasticsearch via configuration files as described here. In these configuration files, you can use the syntax for each setting as described in our Kibana configuration docs and our elasticsearch configuration docs.