Skip to content

ADR: Secret V2 API

Secret Service V2 API

Date: 2023-09-28

Changed: 2024-06-06

Status

Proposed

Context

This extension builds upon the initial ADR osdu/platform/system/home#75 (closed). The Secret Service plays a pivotal role in managing secret pairs from the CSPs. Currently, the Secret Service is actively utilized by DDMS, specifically the Reservoir DDMS and other services like the EDS for secrets management. What began as a POC has now evolved, prompting the consideration of elevating the service to a comprehensive core services offering.

As part of this evolution, there's a need for various alignments, particularly to the Community Implementation (driver-based) and enhancements to the API's maturity, to seamlessly integrate the Secret Service into the core services. One notable deficiency in the original ADR implementation is the absence of fine-grained access control. This proposal is specifically designed to rectify this gap, aiming to implement robust access controls to augment the overall security and functionality of the Secret Service.

Secret Service V1 API:

Key points Implemented API lacking fine-grained access control.

image

Cons:

  • Anyone with the secret.viewer role able to fetch any secret.
  • Not possible to securely keep third-party secrets and platform secrets.

Decision

Secret Service V2 API:

Key points

  • Implement role-based access to secrets based on Entitlements service.
  • Implement fine-grained access to secrets based on ACL.
  • High privileged role admin will allow to Manage secrets, and access to them.
  • The reader role will only allow reading secrets.
  • ACL will stored in Secret Entity.

image.png

API-DOCS: https://community.opengroup.org/osdu/platform/security-and-compliance/secret/-/blob/secret-v2-api/docs/api/secret_openapi.json

Get secret flow:

Untitled Diagram.drawio(40).png

Create/Update secret flow:

Untitled Diagram.drawio(41).png

List secrets flow:

Untitled Diagram.drawio(42).png

Secret admin flow:

Untitled Diagram.drawio(43).png

Consequences

Pros:

  • API will be mature enough to use within the platform as a standard solution for managing secrets.
  • Access to secrets is restricted to users who have the necessary Access Control List (ACL) permissions.
  • Reduced potential secret leak.

Base scenarios:

  1. When a user requests to read a secret, the Secret service verifies the user's roles and Access Control List (ACL) permissions for the requested secret. If the user has the necessary permissions, the secret will be returned, otherwise, an Unauthorized response.
  2. When a owner wants to manage secret, the Secret service verifies that they have editor role and Access Control List (ACL) permissions for the requested secret.
  3. When an admin wants to create a secret, the Secret Service verifies the admin's roles. If the admin has the necessary permissions, the Secret Service will create this secret, otherwise, a 401 Unauthorized response.
Edited by Rustam Lotsmanenko (EPAM)