Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Prepare the Security, Spaces, and Encrypted Saved Objects HTTP APIs for the Serverless offering #161337

Closed
29 of 34 tasks
azasypkin opened this issue Jul 6, 2023 · 4 comments · Fixed by #162087
Closed
29 of 34 tasks

Prepare the Security, Spaces, and Encrypted Saved Objects HTTP APIs for the Serverless offering #161337

azasypkin opened this issue Jul 6, 2023 · 4 comments · Fixed by #162087
Assignees
@jeramysoucy
Labels
blocker Feature:Security/Authentication Platform Security - Authentication Feature:Security/Authorization Platform Security - Authorization Feature:Security/Encrypted Saved Objects Feature:Security/Interactive Setup Platform Security - Interactive setup mode Feature:Security/Session Management Platform Security - Session Management Feature:Security/Sharing Saved Objects Platform Security - Sharing Saved Objects feature Feature:Security/Spaces Platform Security - Spaces feature Feature:Security/User Profile Project:Serverless MVP Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! v8.10.0

Comments

@azasypkin
Copy link
Member

azasypkin commented Jul 6, 2023 •
edited by jeramysoucy
Loading

Summary

Based on @jeramysoucy's comprehensive Platform Security serverless API audit document (ask if you need a link), here's the breakdown of the work required to prepare our HTTP API surface for the Serverless offering (MVP):

Disable HTTP APIs completely

HTTP APIs mentioned in this section shouldn't be registered with the Core's HTTP Router at all if the XXX (name is still TBD) configuration flag is set.

  • All deprecated APIs: GET /api/security/v1/logout, GET /internal/security/v1/me, GET /api/security/v1/oidc/implicit, GET /api/security/v1/oidc, POST /api/security/v1/oidc, POST /api/security/v1/saml. Note that /api/security/v1/oidc/* will already be disabled in Serverless since OIDC provider isn't configured. Related to Migrate from path based versioning to header based versioning #159181.
  • All authentication-related APIs, except for those specified in the "Mark HTTP APIs as internal" and "Keep HTTP APIs as public" sections.
    • We're keeping the login route (/internal/security/login) for now, as it is used heavily in cypress and UI tests
  • All authorization-related APIs
    • We're keeping role APIs for now, as they are used heavily in cypress and UI tests
  • All role mappings APIs
  • All user management APIs (/internal/security/users/*) - We're keeping user APIs for now, as they are used heavily in cypress and UI tests
  • POST /api/security/session/_invalidate (Invalidate user sessions API)
  • All /internal/security/anonymous_access/* (Anonymous access) APIs
  • All /internal/security/access_agreement/* (Access agreement) APIs and HTTP resources routes (GET /security/access_agreement)
  • GET /internal/security/login_state and GET /login (Login page and selector) - We're keeping login routes for now, as they are used heavily in cypress and UI tests
  • All miscellaneous APIs (see Misc in Platform Security serverless API audit document), except for those specified in the "Mark HTTP APIs as internal" section
  • All /api/spaces/* and /internal/spaces/* APIs, except for those specified in the "Mark HTTP APIs as internal" and "Keep HTTP APIs as public" sections
  • All /api/encrypted_saved_objects/* APIs (Encrypted Saved Objects)
  • All /internal/interactive_setup/* APIs (Interactive Setup). Note that these APIs are already disabled since the entire plugin is disabled

Mark HTTP APIs as internal

HTTP APIs mentioned in this section should stay enabled, but be registered with access: 'internal' flag and will be marked as internal automatically by default.

  • GET /internal/security/me (Get current user)
  • All /internal/security/api_key/* (API key management) APIs
  • All /internal/security/user_profile/* (User profile management) APIs
  • GET /internal/security/session (Get session)
  • POST /internal/security/session (Extend session)
  • GET /internal/security/analytics/_record_auth_type (Get record auth type for analytics purposes)
  • GET /api/spaces/space (Get all Kibana Spaces). This API is required by the Space selector that will be present in the Serverless MVP. In the future, when we allow other Space management capabilities, this API might be upgraded to a public one. See PR Prepare the Security domain HTTP APIs for Serverless #162087
  • GET /api/spaces/space/{id} (Get space). This API is required to retrieve properties of the default Space in the Serverless MVP. In the future, when we allow other Space management capabilities, this API might be upgraded to a public one.See PR Prepare the Security domain HTTP APIs for Serverless #162087
  • PUT /api/spaces/space/{id} (Update space). This API is required to update properties of the default Space in the Serverless MVP. In the future, when we allow other Space management capabilities, this API might be upgraded to a public one. See PR Prepare the Security domain HTTP APIs for Serverless #162087 This API is actually disabled for MVP.
  • GET /internal/spaces/_active_space (Get active space). This API is required by the Space navigation control that will be present in the Serverless MVP. This API will be already treated as internal based on the /internal path prefix, but having access: flag is still recommended for consistency.

Keep HTTP APIs as public

HTTP APIs mentioned in this section should stay enabled, but be registered with access: 'public' flag.

  • GET /api/security/logout (Generic logout). We redirect user to this URL and hence cannot send any additional HTTP headers that internal endpoint would require.
  • POST /api/security/saml/callback (SAML Login). This is the only authentication method that can be used for Kibana in the Serverless offering.

The HTTP APIs mentioned below are not technically APIs, they are endpoints that serve resources or HTML pages (registered with core.http.httpResources.register). Although they are not public, we cannot label them as internal either, as there is no way to attach a special HTTP header to them.

  • GET /internal/security/capture-url (Captures user's URL during SAML handshake)
  • GET /security/account (User profile page)
  • GET /security/logged_out (Logged out page)
  • GET /logout (Logout service page)
  • GET /security/overwritten_session (Overwritten session, technically possible even in Serverless)
  • GET /spaces/space_selector (Spaces selector)
  • GET /spaces/enter (Space entry point)

Blocked by: #161930
@azasypkin azasypkin added blocker Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! Feature:Security/Authentication Platform Security - Authentication Feature:Security/Spaces Platform Security - Spaces feature Feature:Security/Authorization Platform Security - Authorization Feature:Security/Interactive Setup Platform Security - Interactive setup mode Feature:Security/Sharing Saved Objects Platform Security - Sharing Saved Objects feature Feature:Security/Encrypted Saved Objects Feature:Security/Session Management Platform Security - Session Management Feature:Security/User Profile Project:Serverless MVP v8.10.0 labels Jul 6, 2023
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-security (Team:Security)

@jeramysoucy
Copy link
Contributor

@azasypkin When marking existing public API's as internal for serverlvess, do we want to change the route path with 'internal'? Or will this be more of a pain than it's worth?
e.g. GET /api/spaces/space in non-serverles -> GET /internal/spaces/space in serverless

@azasypkin
Copy link
Member Author

@azasypkin When marking existing public API's as internal for serverlvess, do we want to change the route path with 'internal'? Or will this be more of a pain than it's worth?

Nope, I believe we just need a tag, these APIs should stay public for on-prem anyway. And we might make some of them public in the serverless at some point too.

@jeramysoucy jeramysoucy mentioned this issue Jul 17, 2023
Merged
@jeramysoucy jeramysoucy self-assigned this Jul 19, 2023
@TinaHeiligers
Copy link
Contributor

TinaHeiligers commented Jul 20, 2023 •
edited
Loading

@jeramysoucy
From the issue description:

Mark HTTP APIs as internal

You don't need to do anything. They are already internal by default.

Keep HTTP APIs as public

The work moved here. These are internal by default and have to be declared as public. Add access: public. The tag has to be set explicitly.

This was referenced Jul 24, 2023
Closed
Merged
jeramysoucy added a commit that referenced this issue Jul 26, 2023
@jeramysoucy @kibanamachine
Sets logout and saml callback APIs as public in serverless (#162523)
e8a705e 
Subset of #161337
Unblocks #162149

## Summary

This PR uses the access 'public' option when registering the `GET
/api/security/logout` and `POST /api/security/saml/callback` APIs. This
will ensure they have public access in serverless, while all other APIs
will default to internal. PR #161672 changes default access of
registered endpoints to 'internal', meaning that API owners have to
explicitly set access: public to pass the API protection restriction.

This PR also adds internal headers to the existing serverless Spaces API
tests. This unblocks the PR to enable API protection in serverless
(#162149).

---------

Co-authored-by: kibanamachine <[email protected]>
ThomThomson pushed a commit to ThomThomson/kibana that referenced this issue Aug 1, 2023
@jeramysoucy @kibanamachine
Sets logout and saml callback APIs as public in serverless (elastic#1…
b786005 
…62523)

Subset of elastic#161337
Unblocks elastic#162149

## Summary

This PR uses the access 'public' option when registering the `GET
/api/security/logout` and `POST /api/security/saml/callback` APIs. This
will ensure they have public access in serverless, while all other APIs
will default to internal. PR elastic#161672 changes default access of
registered endpoints to 'internal', meaning that API owners have to
explicitly set access: public to pass the API protection restriction.

This PR also adds internal headers to the existing serverless Spaces API
tests. This unblocks the PR to enable API protection in serverless
(elastic#162149).

---------

Co-authored-by: kibanamachine <[email protected]>
@jeramysoucy jeramysoucy mentioned this issue Aug 17, 2023
Open
azasypkin added a commit that referenced this issue Aug 23, 2023
@jeramysoucy @kibanamachine @azasypkin
Prepare the Security domain HTTP APIs for Serverless (#162087)
fe0ffab 
Closes #161337

## Summary

Uses build flavor(see #161930) to disable specific Kibana security,
spaces, and encrypted saved objects HTTP API routes in serverless (see
details in #161337). HTTP APIs that will be public in serverless have
been handled in #162523.

**IMPORTANT: This PR leaves login, user, and role routes enabled. The
primary reason for this is due to several testing mechanisms that rely
on basic authentication and custom roles (UI, Cypress). These tests will
be modified to use SAML authentication and serverless roles in the
immediate future. Once this occurs, we will disable these routes.**

### Testing
This PR also implements testing API access in serverless.
- The testing strategy for disabled routes in serverless is to verify a
`404 not found `response.
- The testing strategy for internal access routes in serverless is to
verify that without the internal request header
(`x-elastic-internal-origin`), a `400 bad request response` is received,
then verify that with the internal request header, a `200 ok response`
is received.
- The strategy for public routes in serverless is to verify a `200 ok`
or `203 redirect` is received.

~~blocked by #161930~~
~~blocked by #162149 for test implementation~~

---------

Co-authored-by: kibanamachine <[email protected]>
Co-authored-by: Aleh Zasypkin <[email protected]>
Co-authored-by: Aleh Zasypkin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jeramysoucy jeramysoucy

Labels
blocker Feature:Security/Authentication Platform Security - Authentication Feature:Security/Authorization Platform Security - Authorization Feature:Security/Encrypted Saved Objects Feature:Security/Interactive Setup Platform Security - Interactive setup mode Feature:Security/Session Management Platform Security - Session Management Feature:Security/Sharing Saved Objects Platform Security - Sharing Saved Objects feature Feature:Security/Spaces Platform Security - Spaces feature Feature:Security/User Profile Project:Serverless MVP Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! v8.10.0
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Prepare the Security domain HTTP APIs for Serverless jeramysoucy/kibana
4 participants
@azasypkin @TinaHeiligers @elasticmachine @jeramysoucy