Encrypted saved objects unusable after key change: isolating Kibana alerting connector secrets in a test cluster
0 reputation · 05 Nov 2020, 22:02 UTC
Goal
I want to integration-test Kibana Alerting rules end to end without putting production connector credentials (email, Slack, PagerDuty) into the test cluster. My plan is to use server log and webhook connectors pointed at a local listener, and validate rule scheduling, action templating, and connector test execution against that controlled sink.
Constraint
Connector secrets are stored via Kibana's encrypted saved objects service, which depends on the configured encryption key being present and identical across all Kibana nodes. A documented failure condition is that existing encrypted saved objects become unusable when the key is missing, changed, or not shared. I am unsure how to isolate test credentials safely: reusing the production key with redacted connectors feels risky, but a separate key means I cannot copy any existing connector saved objects into the test cluster.
Questions
- When the encryption key differs or is absent, do connectors fail at Kibana startup, on decryption, or only when an action executes, and does this vary by version?
- Is a separate test key plus fixture secrets the accepted isolation pattern, or is there a supported external secret-injection mechanism for connectors?
- Can I safely verify decryption health from Kibana logs without exposing secret material?