## Summary Closes https://github.com/elastic/observability-dev/issues/4539 Fixes https://github.com/elastic/kibana/issues/221035 Enables custom roles for Observability projects in serverless. The following is a summary of the changes: ## Feature renaming 1. Renamed `Uptime and Synthetics` to `Synthetics` 2. Renamed `APM and User Experience` to `Applications` 3. Renamed `Metrics` to `Infrastructure` ## Category reassignment 1. Changed `Dashboard` category from `Analytics` to `Observability` 2. Changed `Discover` category from `Analytics` to `Observability` 3. Changed `ML` category from `Analytics` to `Observability` ## Feature hiding 1. Hides the `Stack Alerts` feature. 2. Provides backwards compatibility for alerts created via Stack Alerts. This enables our users to import rules created within Stack Alerts and expect to see them in the Observability rules table. ## Navigation updates 1. Adds a `Custom Roles` link under the `Access` section in the management navigation 2. Adds a `Manage Organization Members` link under the `Access` section in the management navigation 3. Removes the `Users and Roles` link from the navigation footer (in favor of the `Manage Organization Members link) ## Bug fixes 1. Fixes a bug where the `Alerts` link was not shown for Synthetics only user (in stateful and serverless) 2. Fixes a bug where the `Alerts` link was not shown for Logs only user (in stateful and serverless) ## Alert Override Removal In the alerting framework, each rule is assigned a `consumer` value. This `consumer` value changes depending on where the rule is created in Kibana. However, in serverless we introduced an override that caused the `consumer` value to be `Observability` in nearly every case. This logic branched from stateful causing complexity and a large mental burden for our engineers. Ultimately, this override became the source of bugs, uncertainty, and unintended user experiences. Because of this, we've removed this overrides. If we kept this override, it would have the unfortunate side effect of making all rules created in serverless visible from all custom roles (an APM only user would have been can see Synthetics rules, and vice versus). To make things more unpredictable, when users import their rules from stateful the behavior would be different (access would be properly mapped to the specific feature). To address these specific user experience issues, and remove the source of complexity, branching logic, and bugs, we removed this override logic and restored the rule access behavior to match with stateful. We did this while introducing backwards compatibility logic, ensuring rules created in earlier versions of an oblt stateful cluster continue to work and are accessible by a user with the right role access. # Testing 1. Run local ES ``` yarn es serverless --projectType=oblt -E xpack.security.authc.native_roles.enabled=true ``` 2. Run local Kibana ``` yarn start --serverless=oblt --xpack.security.roleManagementEnabled=true --xpack.cloud.users_and_roles_url="https://test_users_and_roles_url" ``` 3. Login to Kibana with the admin role. Navigate to the Custom Roles page via the management navigation. 4. Create a custom role 5. Log out of Kibana 6. Log back in with your custom role. You can do so by typing the custom role name into the mock saml auth <img width="460" alt="Screenshot 2025-05-22 at 9 23 13 PM" src="https://github.com/user-attachments/assets/8e7f659b-5fe9-4e74-8c57-b420467d309e" /> --------- Co-authored-by: Jason Rhodes <jason.rhodes@elastic.co> Co-authored-by: Faisal Kanout <faisal.kanout@elastic.co> Co-authored-by: “jeramysoucy” <jeramy.soucy@elastic.co> |
||
---|---|---|
.buildkite | ||
.devcontainer | ||
.github | ||
api_docs | ||
config | ||
dev_docs | ||
docs | ||
examples | ||
kbn_pm | ||
legacy_rfcs | ||
licenses | ||
oas_docs | ||
packages | ||
plugins | ||
scripts | ||
src | ||
typings | ||
x-pack | ||
.backportrc.json | ||
.bazelignore | ||
.bazeliskversion | ||
.bazelrc | ||
.bazelrc.common | ||
.bazelversion | ||
.browserslistrc | ||
.editorconfig | ||
.eslintignore | ||
.eslintrc.js | ||
.gitattributes | ||
.gitignore | ||
.i18nrc.json | ||
.node-version | ||
.npmrc | ||
.nvmrc | ||
.prettierignore | ||
.prettierrc | ||
.puppeteerrc | ||
.stylelintignore | ||
.stylelintrc | ||
.telemetryrc.json | ||
.yarnrc | ||
BUILD.bazel | ||
catalog-info.yaml | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
FAQ.md | ||
fleet_packages.json | ||
github_checks_reporter.json | ||
kibana.d.ts | ||
LICENSE.txt | ||
NOTICE.txt | ||
package.json | ||
preinstall_check.js | ||
README.md | ||
renovate.json | ||
RISK_MATRIX.mdx | ||
run_fleet_setup_parallel.sh | ||
SECURITY.md | ||
sonar-project.properties | ||
STYLEGUIDE.mdx | ||
tsconfig.base.json | ||
tsconfig.browser.json | ||
tsconfig.browser_bazel.json | ||
tsconfig.json | ||
TYPESCRIPT.md | ||
updatecli-compose.yaml | ||
versions.json | ||
WORKSPACE.bazel | ||
yarn.lock |
Kibana
Kibana is your window into the Elastic Stack. Specifically, it's a browser-based analytics and search dashboard for Elasticsearch.
- Getting Started
- Documentation
- Version Compatibility with Elasticsearch
- Questions? Problems? Suggestions?
Getting Started
If you just want to try Kibana out, check out the Elastic Stack Getting Started Page to give it a whirl.
If you're interested in diving a bit deeper and getting a taste of Kibana's capabilities, head over to the Kibana Getting Started Page.
Using a Kibana Release
If you want to use a Kibana release in production, give it a test run, or just play around:
- Download the latest version on the Kibana Download Page.
- Learn more about Kibana's features and capabilities on the Kibana Product Page.
- We also offer a hosted version of Kibana on our Cloud Service.
Building and Running Kibana, and/or Contributing Code
You might want to build Kibana locally to contribute some code, test out the latest features, or try out an open PR:
- CONTRIBUTING.md will help you get Kibana up and running.
- If you would like to contribute code, please follow our STYLEGUIDE.mdx.
- For all other questions, check out the FAQ.md and wiki.
Documentation
Visit Elastic.co for the full Kibana documentation.
For information about building the documentation, see the README in elastic/docs.
Version Compatibility with Elasticsearch
Ideally, you should be running Elasticsearch and Kibana with matching version numbers. If your Elasticsearch has an older version number or a newer major number than Kibana, then Kibana will fail to run. If Elasticsearch has a newer minor or patch number than Kibana, then the Kibana Server will log a warning.
Note: The version numbers below are only examples, meant to illustrate the relationships between different types of version numbers.
Situation | Example Kibana version | Example ES version | Outcome |
---|---|---|---|
Versions are the same. | 7.15.1 | 7.15.1 | 💚 OK |
ES patch number is newer. | 7.15.0 | 7.15.1 | ⚠️ Logged warning |
ES minor number is newer. | 7.14.2 | 7.15.0 | ⚠️ Logged warning |
ES major number is newer. | 7.15.1 | 8.0.0 | 🚫 Fatal error |
ES patch number is older. | 7.15.1 | 7.15.0 | ⚠️ Logged warning |
ES minor number is older. | 7.15.1 | 7.14.2 | 🚫 Fatal error |
ES major number is older. | 8.0.0 | 7.15.1 | 🚫 Fatal error |
Questions? Problems? Suggestions?
- If you've found a bug or want to request a feature, please create a GitHub Issue. Please check to make sure someone else hasn't already created an issue for the same topic.
- Need help using Kibana? Ask away on our Kibana Discuss Forum and a fellow community member or Elastic engineer will be glad to help you out.