# Kibana Security Exception When Viewing Rules/Alerts
**URL:** https://discuss.elastic.co/t/kibana-security-exception-when-viewing-rules-alerts/297174
**Category:** Kibana
**Tags:** elastic-stack-alerting
**Created:** [February 14, 2022, 5:42pm UTC](https://discuss.elastic.co/t/kibana-security-exception-when-viewing-rules-alerts/297174 "2022-02-14T17:42:40Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@DougR](https://discuss.elastic.co/u/DougR)
#### Post date: [February 14, 2022, 5:42pm UTC](https://discuss.elastic.co/t/kibana-security-exception-when-viewing-rules-alerts/297174/1 "2022-02-14T17:42:40Z")
I'm configuring Elastic Security with for Elastic Stack 7.16.3. When I visit Stack Management-\>Rules and Connectors in Kibana, I see the following:
...and this is the specific error that shows up when I hover over the Error status:
When I look at the actual logs, it's littered with log entries like this:
```json
{
"type": "log",
"@timestamp": "2022-02-14T17:19:43+00:00",
"tags": [
"error",
"plugins",
"alerting"
],
"pid": 8,
"message": "Executing Alert default:monitoring_alert_cpu_usage:b32b3780-22bd-11ec-9456-c3f758019dc7 has resulted in Error: security_exception: [security_exception] Reason: missing authentication credentials for REST request [/_security/user/_has_privileges], caused by: \"\""
}
```
Here's the relevant portion of my `kibana.yml`:
```nohighlight
# Configure connection to Elasticsearch
elasticsearch:
username: '${KIBANA_SYSTEM_USERNAME}'
password: '${KIBANA_SYSTEM_PASSWORD}'
ssl:
alwaysPresentCertificate: false
certificate: '/usr/share/kibana/config/certs/cert.pem'
key: '/usr/share/kibana/config/certs/key.pem'
certificateAuthorities:
- '/usr/share/kibana/config/certs/ca_bundle.pem'
verificationMode: 'none'
```
Other than this, Kibana appears to connect just fine with this configuration (i.e., I can perform admin functions and search Elasticsearch from Kibana).
I previously had `xpack.security.disabled: false` set on this stack, if it matters, and so I was wondering whether [this reply](https://github.com/elastic/kibana/issues/118520#issuecomment-973105804) to [Issue #118520](https://github.com/elastic/kibana/issues/118520) might apply.
I don't currently have any credentials, etc. configured, so is there an index that I can delete/recreate at restart that will resolve this issue, or some similar solution? I have data, which I need to preserve, so simply deleting my stack and restarting from scratch isn't really an option.
---
### Author:  [@DougR](https://discuss.elastic.co/u/DougR)
#### Post date: [February 21, 2022, 4:49pm UTC](https://discuss.elastic.co/t/kibana-security-exception-when-viewing-rules-alerts/297174/2 "2022-02-21T16:49:33Z")
Figured this out this morning. According to the [Authorization](https://www.elastic.co/guide/en/kibana/current/alerting-setup.html#alerting-authorization) section of the [Alerting Setup](https://www.elastic.co/guide/en/kibana/current/alerting-setup.html) page:
> Rules are authorized using an [API key](https://www.elastic.co/guide/en/kibana/current/api-keys.html) associated with the last user to edit the rule. This API key captures a snapshot of the user’s privileges at the time of edit and is subsequently used to run all background tasks associated with the rule, including condition checks, like Elasticsearch queries, and action executions. The following rule actions will re-generate the API key:
>
> - Creating a rule
> - Enabling a disabled rule
> - Updating a rule
Since these rules were for a brand new stack, they'd never been saved before by a user. Once I went in and saved the rules with the `elastic` user, the rules started running as expected. Again, I had initially configured this stack with `xpack.security.enabled: false`, so this may not be an issue if security is configured initially.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [March 21, 2022, 4:50pm UTC](https://discuss.elastic.co/t/kibana-security-exception-when-viewing-rules-alerts/297174/3 "2022-03-21T16:50:22Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.