You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the observability plugin (x-pack/plugins/observability_solution/observability), the following API routes don't appear to use the access tag for specifying whether the route is public or private/internal. We need to verify if that's the case and if so, fix them so they use this access tag (and not rely on default behavior or path conventions).
Route
Intended Access
POST /api/observability/annotation
public
PUT /api/observability/annotation/{id}
public
DELETE /api/observability/annotation/{id}
public
GET /api/observability/annotation/{id}
public
GET /api/observability/annotation/find
public
GET /api/observability/annotation/permissions
public
GET /internal/observability/assistant/alert_details_contextual_insights
private/internal
GET /api/observability/rules/alerts/dynamic_index_pattern
public
Note: if any/all of these route definitions make use of the kbn-server-route-repository package, it's possible that package is applying the access tag behind the scenes, based on the route's path. We should confirm if this is the case, but also verify whether the route repository package's tools allow us to specify the explicit access tag anyway, to avoid relying on the implicit convention.
The text was updated successfully, but these errors were encountered:
jasonrhodes
changed the title
[Observability plugin] Check API routes for correct access: tags
[Observability plugin] Use correct access: tags in observability plugin API routes
Sep 24, 2024
In the observability plugin (x-pack/plugins/observability_solution/observability), the following API routes don't appear to use the
access
tag for specifying whether the route is public or private/internal. We need to verify if that's the case and if so, fix them so they use thisaccess
tag (and not rely on default behavior or path conventions).Note: if any/all of these route definitions make use of the kbn-server-route-repository package, it's possible that package is applying the
access
tag behind the scenes, based on the route's path. We should confirm if this is the case, but also verify whether the route repository package's tools allow us to specify the explicit access tag anyway, to avoid relying on the implicit convention.The text was updated successfully, but these errors were encountered: