…astic#198349)

### Authz API migration for unauthorized routes

This PR migrates unauthorized routes owned by your team to a new
security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)

### **Before migration:**
```ts
router.get({
  path: '/api/path',
  ...
}, handler);
```

### **After migration:**
```ts
router.get({
  path: '/api/path',
  security: {
    authz: {
      enabled: false,
      reason: 'This route is opted out from authorization because ...',
    },
  },
  ...
}, handler);
```

### What to do next?
1. Review the changes in this PR.
2. Elaborate on the reasoning to opt-out of authorization.
3. Routes without a compelling reason to opt-out of authorization should
plan to introduce them as soon as possible.
2. You might need to update your tests to reflect the new security
configuration:
  - If you have snapshot tests that include the route definition.

## Any questions?
If you have any questions or need help with API authorization, please
reach out to the `@elastic/kibana-security` team.

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani01@gmail.com>
(cherry picked from commit 4a2de76)

…am (#198349) (#199799)

# Backport

This will backport the following commits from `main` to `8.x`:
- [Unauthorized route migration for routes owned by obs-ux-logs-team
(#198349)](#198349)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Kibana
Machine","email":"42973632+kibanamachine@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-11-12T14:17:12Z","message":"Unauthorized
route migration for routes owned by obs-ux-logs-team (#198349)\n\n###
Authz API migration for unauthorized routes\r\n\r\nThis PR migrates
unauthorized routes owned by your team to a new\r\nsecurity
configuration.\r\nPlease refer to the documentation for more
information:
[Authorization\r\nAPI](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)\r\n\r\n###
**Before migration:**\r\n```ts\r\nrouter.get({\r\n path:
'/api/path',\r\n ...\r\n}, handler);\r\n```\r\n\r\n### **After
migration:**\r\n```ts\r\nrouter.get({\r\n path: '/api/path',\r\n
security: {\r\n authz: {\r\n enabled: false,\r\n reason: 'This route is
opted out from authorization because ...',\r\n },\r\n },\r\n ...\r\n},
handler);\r\n```\r\n\r\n### What to do next?\r\n1. Review the changes in
this PR.\r\n2. Elaborate on the reasoning to opt-out of
authorization.\r\n3. Routes without a compelling reason to opt-out of
authorization should\r\nplan to introduce them as soon as
possible.\r\n2. You might need to update your tests to reflect the new
security\r\nconfiguration:\r\n - If you have snapshot tests that include
the route definition.\r\n\r\n## Any questions?\r\nIf you have any
questions or need help with API authorization, please\r\nreach out to
the `@elastic/kibana-security` team.\r\n\r\nCo-authored-by: Elastic
Machine <elasticmachine@users.noreply.github.com>\r\nCo-authored-by:
Marco Antonio Ghiani
<marcoantonio.ghiani01@gmail.com>","sha":"4a2de76333063a1c6e68eeeaf4697753593928a5","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["enhancement","release_note:skip","Feature:Security/Authorization","v9.0.0","backport:prev-minor","Team:obs-ux-logs","Authz:
API migration"],"title":"Unauthorized route migration for routes owned
by
obs-ux-logs-team","number":198349,"url":"https://github.com/elastic/kibana/pull/198349","mergeCommit":{"message":"Unauthorized
route migration for routes owned by obs-ux-logs-team (#198349)\n\n###
Authz API migration for unauthorized routes\r\n\r\nThis PR migrates
unauthorized routes owned by your team to a new\r\nsecurity
configuration.\r\nPlease refer to the documentation for more
information:
[Authorization\r\nAPI](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)\r\n\r\n###
**Before migration:**\r\n```ts\r\nrouter.get({\r\n path:
'/api/path',\r\n ...\r\n}, handler);\r\n```\r\n\r\n### **After
migration:**\r\n```ts\r\nrouter.get({\r\n path: '/api/path',\r\n
security: {\r\n authz: {\r\n enabled: false,\r\n reason: 'This route is
opted out from authorization because ...',\r\n },\r\n },\r\n ...\r\n},
handler);\r\n```\r\n\r\n### What to do next?\r\n1. Review the changes in
this PR.\r\n2. Elaborate on the reasoning to opt-out of
authorization.\r\n3. Routes without a compelling reason to opt-out of
authorization should\r\nplan to introduce them as soon as
possible.\r\n2. You might need to update your tests to reflect the new
security\r\nconfiguration:\r\n - If you have snapshot tests that include
the route definition.\r\n\r\n## Any questions?\r\nIf you have any
questions or need help with API authorization, please\r\nreach out to
the `@elastic/kibana-security` team.\r\n\r\nCo-authored-by: Elastic
Machine <elasticmachine@users.noreply.github.com>\r\nCo-authored-by:
Marco Antonio Ghiani
<marcoantonio.ghiani01@gmail.com>","sha":"4a2de76333063a1c6e68eeeaf4697753593928a5"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/198349","number":198349,"mergeCommit":{"message":"Unauthorized
route migration for routes owned by obs-ux-logs-team (#198349)\n\n###
Authz API migration for unauthorized routes\r\n\r\nThis PR migrates
unauthorized routes owned by your team to a new\r\nsecurity
configuration.\r\nPlease refer to the documentation for more
information:
[Authorization\r\nAPI](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)\r\n\r\n###
**Before migration:**\r\n```ts\r\nrouter.get({\r\n path:
'/api/path',\r\n ...\r\n}, handler);\r\n```\r\n\r\n### **After
migration:**\r\n```ts\r\nrouter.get({\r\n path: '/api/path',\r\n
security: {\r\n authz: {\r\n enabled: false,\r\n reason: 'This route is
opted out from authorization because ...',\r\n },\r\n },\r\n ...\r\n},
handler);\r\n```\r\n\r\n### What to do next?\r\n1. Review the changes in
this PR.\r\n2. Elaborate on the reasoning to opt-out of
authorization.\r\n3. Routes without a compelling reason to opt-out of
authorization should\r\nplan to introduce them as soon as
possible.\r\n2. You might need to update your tests to reflect the new
security\r\nconfiguration:\r\n - If you have snapshot tests that include
the route definition.\r\n\r\n## Any questions?\r\nIf you have any
questions or need help with API authorization, please\r\nreach out to
the `@elastic/kibana-security` team.\r\n\r\nCo-authored-by: Elastic
Machine <elasticmachine@users.noreply.github.com>\r\nCo-authored-by:
Marco Antonio Ghiani
<marcoantonio.ghiani01@gmail.com>","sha":"4a2de76333063a1c6e68eeeaf4697753593928a5"}}]}]
BACKPORT-->

…astic#198349)

### Authz API migration for unauthorized routes

This PR migrates unauthorized routes owned by your team to a new
security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)

### **Before migration:**
```ts
router.get({
  path: '/api/path',
  ...
}, handler);
```

### **After migration:**
```ts
router.get({
  path: '/api/path',
  security: {
    authz: {
      enabled: false,
      reason: 'This route is opted out from authorization because ...',
    },
  },
  ...
}, handler);
```

### What to do next?
1. Review the changes in this PR.
2. Elaborate on the reasoning to opt-out of authorization.
3. Routes without a compelling reason to opt-out of authorization should
plan to introduce them as soon as possible.
2. You might need to update your tests to reflect the new security
configuration:
  - If you have snapshot tests that include the route definition.

## Any questions?
If you have any questions or need help with API authorization, please
reach out to the `@elastic/kibana-security` team.

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani01@gmail.com>

…#199774)

## 📓 Summary

Related to #198349 

Disabling authorization on fields metadata `find API` implies every user
would have access to the integration fields since we use the internal
user to retrieve the package information.

On the other hand, requiring API root-level privileges for `fleet` and
`fleetv2` would restrict more use cases since other apps might rely on
this service to consume field metadata from ECS only, with no need for
integration permissions (Discover, etc.).

To keep the door open to all these use cases, we'll check the available
user privileges on a per-request basis and allow integration fields only
when they have access to fleet and integrations, without fully
restricting the service.


https://github.com/user-attachments/assets/49b9953a-f1e1-410a-8c7f-c38d87408fcc

---------

Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>

…elastic#199774)

## 📓 Summary

Related to elastic#198349

Disabling authorization on fields metadata `find API` implies every user
would have access to the integration fields since we use the internal
user to retrieve the package information.

On the other hand, requiring API root-level privileges for `fleet` and
`fleetv2` would restrict more use cases since other apps might rely on
this service to consume field metadata from ECS only, with no need for
integration permissions (Discover, etc.).

To keep the door open to all these use cases, we'll check the available
user privileges on a per-request basis and allow integration fields only
when they have access to fleet and integrations, without fully
restricting the service.

https://github.com/user-attachments/assets/49b9953a-f1e1-410a-8c7f-c38d87408fcc

---------

Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
(cherry picked from commit 45056f3)

…ileges (#199774) (#200676)

# Backport

This will backport the following commits from `main` to `8.x`:
- [[Fields Metadata] Restrict access to integration fields by privileges
(#199774)](#199774)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Marco Antonio
Ghiani","email":"marcoantonio.ghiani01@gmail.com"},"sourceCommit":{"committedDate":"2024-11-19T08:00:22Z","message":"[Fields
Metadata] Restrict access to integration fields by privileges
(#199774)\n\n## 📓 Summary\r\n\r\nRelated to #198349 \r\n\r\nDisabling
authorization on fields metadata `find API` implies every user\r\nwould
have access to the integration fields since we use the internal\r\nuser
to retrieve the package information.\r\n\r\nOn the other hand, requiring
API root-level privileges for `fleet` and\r\n`fleetv2` would restrict
more use cases since other apps might rely on\r\nthis service to consume
field metadata from ECS only, with no need for\r\nintegration
permissions (Discover, etc.).\r\n\r\nTo keep the door open to all these
use cases, we'll check the available\r\nuser privileges on a per-request
basis and allow integration fields only\r\nwhen they have access to
fleet and integrations, without fully\r\nrestricting the
service.\r\n\r\n\r\nhttps://github.com/user-attachments/assets/49b9953a-f1e1-410a-8c7f-c38d87408fcc\r\n\r\n---------\r\n\r\nCo-authored-by:
Marco Antonio Ghiani
<marcoantonio.ghiani@elastic.co>","sha":"45056f3abb268048e27ac297e4f9238ac86dba69","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","backport:prev-minor","Team:obs-ux-logs"],"title":"[Fields
Metadata] Restrict access to integration fields by
privileges","number":199774,"url":"https://github.com/elastic/kibana/pull/199774","mergeCommit":{"message":"[Fields
Metadata] Restrict access to integration fields by privileges
(#199774)\n\n## 📓 Summary\r\n\r\nRelated to #198349 \r\n\r\nDisabling
authorization on fields metadata `find API` implies every user\r\nwould
have access to the integration fields since we use the internal\r\nuser
to retrieve the package information.\r\n\r\nOn the other hand, requiring
API root-level privileges for `fleet` and\r\n`fleetv2` would restrict
more use cases since other apps might rely on\r\nthis service to consume
field metadata from ECS only, with no need for\r\nintegration
permissions (Discover, etc.).\r\n\r\nTo keep the door open to all these
use cases, we'll check the available\r\nuser privileges on a per-request
basis and allow integration fields only\r\nwhen they have access to
fleet and integrations, without fully\r\nrestricting the
service.\r\n\r\n\r\nhttps://github.com/user-attachments/assets/49b9953a-f1e1-410a-8c7f-c38d87408fcc\r\n\r\n---------\r\n\r\nCo-authored-by:
Marco Antonio Ghiani
<marcoantonio.ghiani@elastic.co>","sha":"45056f3abb268048e27ac297e4f9238ac86dba69"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/199774","number":199774,"mergeCommit":{"message":"[Fields
Metadata] Restrict access to integration fields by privileges
(#199774)\n\n## 📓 Summary\r\n\r\nRelated to #198349 \r\n\r\nDisabling
authorization on fields metadata `find API` implies every user\r\nwould
have access to the integration fields since we use the internal\r\nuser
to retrieve the package information.\r\n\r\nOn the other hand, requiring
API root-level privileges for `fleet` and\r\n`fleetv2` would restrict
more use cases since other apps might rely on\r\nthis service to consume
field metadata from ECS only, with no need for\r\nintegration
permissions (Discover, etc.).\r\n\r\nTo keep the door open to all these
use cases, we'll check the available\r\nuser privileges on a per-request
basis and allow integration fields only\r\nwhen they have access to
fleet and integrations, without fully\r\nrestricting the
service.\r\n\r\n\r\nhttps://github.com/user-attachments/assets/49b9953a-f1e1-410a-8c7f-c38d87408fcc\r\n\r\n---------\r\n\r\nCo-authored-by:
Marco Antonio Ghiani
<marcoantonio.ghiani@elastic.co>","sha":"45056f3abb268048e27ac297e4f9238ac86dba69"}}]}]
BACKPORT-->

Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani01@gmail.com>

…elastic#199774)

## 📓 Summary

Related to elastic#198349 

Disabling authorization on fields metadata `find API` implies every user
would have access to the integration fields since we use the internal
user to retrieve the package information.

On the other hand, requiring API root-level privileges for `fleet` and
`fleetv2` would restrict more use cases since other apps might rely on
this service to consume field metadata from ECS only, with no need for
integration permissions (Discover, etc.).

To keep the door open to all these use cases, we'll check the available
user privileges on a per-request basis and allow integration fields only
when they have access to fleet and integrations, without fully
restricting the service.


https://github.com/user-attachments/assets/49b9953a-f1e1-410a-8c7f-c38d87408fcc

---------

Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>