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.

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

[META] Diagrams for New Security Model #2654

Closed
DarshitChanpura opened this issue Apr 6, 2023 · 4 comments
Closed

[META] Diagrams for New Security Model #2654

DarshitChanpura opened this issue Apr 6, 2023 · 4 comments
Labels
triaged Issues labeled as 'Triaged' have been reviewed and are deemed actionable.

Comments

@DarshitChanpura
Copy link
Member

DarshitChanpura commented Apr 6, 2023

This is a central (evolving) place for all design diagrams created as part of the new security model. These are identified by following sections:

  1. High-level View
  2. Security <> Plugin Interactions
  3. Security <> Extension Interactions
  4. Authentication
  5. Service Account for Extensions
  6. Authorization
  7. Async Ops

High-level View

TBD

Security <> Plugin Interactions

This area focuses on how plugins interact with the current security model.

sequenceDiagram
    actor Client;
    participant OpenSearch;
    participant Security Plugin as Security Plugin<br>In OpenSearch Process;
    participant Plugin Handler as Plugin Handler<br>In OpenSearch Process;

    Client->>OpenSearch: Request
    OpenSearch->>Security Plugin: Lookup AuthN and perform AuthZ check
    Security Plugin->>OpenSearch: Inject user information into context
    OpenSearch->>Plugin Handler: Invoke plugin handler class
    alt Optional Plugin Actions
    Plugin Handler->>OpenSearch: Perform additional actions on behalf of user
    OpenSearch-->>Plugin Handler: Result
    end
    Plugin Handler-->>OpenSearch: Result
    OpenSearch->>Client: Response
Loading

Security <> Extension Interactions

This area shows the design of the request flow for interactions with extensions via the new Security Plugin model

sequenceDiagram
    actor Client;
    participant OpenSearch;
    participant Security Plugin as Security Plugin<br>Inside OpenSearch JVM;
    participant RestSendToExtension as RestSendToExtension<br>Inside OpenSearch JVM;
    participant Extension Handler as Extension Handler<br>Seperate Host;

    Client->>OpenSearch: Request
    OpenSearch->>Security Plugin: Lookup AuthN and perform AuthZ check
    Security Plugin->>OpenSearch: Inject user information into context
    OpenSearch->>RestSendToExtension: Invoke handler class
    RestSendToExtension->>Security Plugin: Request a on-behalf-of-user auth token
    Security Plugin-->>RestSendToExtension: Provide auth token from context generate
    RestSendToExtension->>Extension Handler: Forwards REST request to extension<br>payload includes auth token
    alt Optional Extension Actions
    Extension Handler->>OpenSearch: Perform additional actions with on behalf of user token
    OpenSearch-->>Extension Handler: Result
    end
    Extension Handler-->>RestSendToExtension: Result
    RestSendToExtension-->>OpenSearch: Result
    OpenSearch->>Client: Response
Loading

Authentication

This area focuses on token-passing and token-handling when an external entity wants to interact with OpenSearch cluster on-behalf-of a user.

OpenSearch_JIT_Extension

Service Account for Extensions

This area specifically focuses on service accounts for extensions to allow them to interact with OpenSearch cluster without any

  1. Extension Requests its Service Account (same as registration process)
flowchart TD
    A[Extension_1] -->|Install| B(Core ServiceAccountManager)
    B --> |getOrCreate ServiceAccount|C{Security Plugin}
    C -->| Check ServiceAccount| D[InternalUsers]
    D --> | ServiceAccount Exists | E(Response)
    D --> | ServiceAccount does not exist | F[Create ServiceAccount]
    F --> | Store ServiceAccount | D
    E --> | Return ServiceAccount Info | B
Loading
  1. Cluster administrator requests a list of all service accounts
flowchart TD
    A[Admin_1] -->|REST GET localhost:9200/_extensions/accounts/list| B(Core RestHandler)
    B --> |Forward to Security Plugin|C{Security Plugin}
    C -->| Authorize request| C
    C -->| Access internalUser Storage| D[InternalUsers]
    D --> | Iterate over accounts | D
    D --> | Build response list of all with 'Service' : 'true' | E[ResponseObject]
    E --> | Return ServiceAccount List | B
Loading
  1. Extension tries to execute a request
flowchart TD
    A[Extension_1] -->|Operation Request| B(Core)
    B --> | Redirect to ServiceAccountManager | C(Core ServiceAccountManager)
    C --> |getOrCreate ServiceAccount|D{Security Plugin}
    D -->| Check ServiceAccount| E[InternalUsers]
    E --> | ServiceAccount Exists | F(Response)
    F --> | Return ServiceAccount Info | D
    D --> | Authorize ServiceAccount | D
    D --> | Return Authorization | C
    C --> | Give 200 | B
    B --> | Execute Request | B
Loading

Authorization

This area focuses on the current authorization flow and the new authorization process.

Current Authz Flow

sequenceDiagram
    actor User
    box grey OpenSearch
        participant REST Layer
        participant Transport Layer
        participant Service Layer
    end

    User->>+REST Layer: GET /myidx/_search
    REST Layer-->>+Transport Layer: Calls "indices:data/read/search"
    Transport Layer-->>Transport Layer: User info is read from thread context, and privileges are evaluated
    Transport Layer-->>REST Layer: if user authorization fails
    Transport Layer-->>+Service Layer: If privilege eval is successful, relevant service method is called
    Service Layer-->>Service Layer: Request action is processed
    Service Layer-->>-Transport Layer: Results are returned
    Transport Layer-->>-REST Layer: Response is returned
    REST Layer-->>-User: Request Response is returned
Loading

New Authz Implementation

The new model implements authz check at REST layer to allow privilege evaluation for extensions.

sequenceDiagram
    actor U as User
    
    box grey OpenSearch Cluster
        participant N as Node
        participant R as REST Layer
        participant S as Service Layer
    end
    
    box slategray Extension Realm
        participant E as Extension ext1
    end

    rect rgba(139, 248, 255, .3)
    Note over U,E: Request is for extensions
        U->>+N: GET /_extensions/ext1/aggregateIdx with authn credentials
        N->>+R: Request is intercepted for authn check
        R-->>N: Send 403 on authn failure
        N->>+E: Forwards user request to ext1 with a token that contains user authn info
        E->>E: Process the request
        
        rect rgba(120, 0, 0, .3)
        Note over N,E: Extension needs data access
            E->>+N: Request must contain extension's own identifier + user authn token
            R->>R: 1. Perform auth check <br/> 2. On success call "indices:data/read/search" and perform privilege Eval
            R-->>N: Send 403 on authz failure
            R->>+S: If privilege eval is successful, relevant service method is called
            S->>S: Request action is processed
            S->>-R: Results are returned
            R->>-N: Response is formed and ready to return
            N->>-E: On 200 OK, OS node returns data to extensions for further processing
        end
        
        E->>E: Draft the response
        E->>-N: Returns drafted user response
        N->>-U: Request Response is returned to the user, 200 OK if success else 403/400 on failure
    end

    rect rgba(139, 200, 100, .3)
    Note over U,E: Request is for core
        U->>+N: GET /<index>/_search with authn credentials
        N->>+R: Request is intercepted for authn check
        R-->>N: Send 403 on authn failure
        R->>R: Perform auth check and on success call "indices:data/read/search"
        R->>R: Perform privilege Eval
        R-->>N: Send 403 on authz failure
        R->>+S: If privilege eval is successful, relevant service method is called
        S->>S: Request action is processed
        S->>-R: Results are returned
        R->>-N: Response is formed and ready to return
        N->>-U: Request Response is returned to the user, 200 OK if success else 403/400 on failure
    end
    
Loading

Request Flow

---
title: API Request Flow
---
flowchart TB
    Request((Request)) --> |An API Request is received Opensearch| OpenSearch
    OpenSearch --> |Identifies the handler to be called| RestController
    RestController --> |Request is meant for core| BaseRestHandler
    RestController --> |Request is meant for extension| ExtensionRestHandler
    BaseRestHandler & ExtensionRestHandler --> |Before handler is invoked, <br> request is intercepted by wrapper| Wrapper
    Wrapper --> |Perform authentication & authorization at REST Layer| Check{AuthN-AuthZ check}
    Check --> |Failure, 403 Unauthorized| Response((Response))
    Check -->|Success, proceed with original rest handler| OriginalRestHandler
    OriginalRestHandler --> |Process the request and form the response| OriginalRestHandler
    OriginalRestHandler --> |Return the response, 200 OK| Response
Loading

Async Ops

TBD

@github-actions github-actions bot added the untriaged Require the attention of the repository maintainers and may need to be prioritized label Apr 6, 2023
@peternied
Copy link
Member

@DarshitChanpura Thanks for rounding these up - what do you think about rebuilding some of these diagrams together?

I think we need the following kinds of interactions mapped out including all of the new features we are adding:

  • The types of data traveling between the trust boundary between an OpenSearch cluster and an Extensions. What is encrypted, tamperproof, or plain text.
  • The existing feature (such as authenticating backends, or service account on internal users) where we are building on with the expanded functionality called out

@peternied
Copy link
Member

Note; I'm not sure we will be able to make a readable chart that is also mermaid - so take a look at your own preference for clarity of reading / ease of building

@stephen-crawford stephen-crawford added triaged Issues labeled as 'Triaged' have been reviewed and are deemed actionable. and removed untriaged Require the attention of the repository maintainers and may need to be prioritized labels Apr 10, 2023
@stephen-crawford
Copy link
Contributor

[Triage] This issue is part of the ongoing work with the extensions project.

@davidlago
Copy link

Cosing this for now. We can use this to turn it into an .md doc we can add in our repo, but as an issue goes, I'm not sure this should continue to be open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triaged Issues labeled as 'Triaged' have been reviewed and are deemed actionable.
Projects
Status: Done
Development

No branches or pull requests

4 participants