Projects & Global Secrets

[rohan-chaturvedi]

We're looking for feedback and input on two new planned features that are related: Projects and Global Secrets. The overarching motivation with these features is to allow users to map secrets and configuration in Phase more closely with their development and deployment workflows, and add a dimension for more sophisticated, hierarchical secrets management setups.

Projects

A new layer of abstraction in Phase that allows groupings of related apps.

Projects are a way to group related apps that are part of a single application, or stack. Projects will make it easier to manage access, integrations and settings for a set of apps, and allow for shared secrets and configuration to be defined across the project.

Motivation

Currently, Apps in an org exist on a flat tier, but often certain apps are related and are part of a larger single application. For example consider the Phase Apps dashboard - backend and dashboard - frontendwhere the backend and frontend have their own respective repos, secrets, team members, but are part of the dashboard application which has a common context. The current flat organisation of Apps makes this cumbersome to map correctly, and mixes it in with all other Apps in the org.

Projects will allow for related apps to be grouped. For example:

└── dashboard
        ├── frontend
        └── backend

Implementation

The basic implementation of Projects would include:

• Project CRUD

  • Create, manage and delete projects.
  • Add or remove apps from projects

• Project Access

  • View and manage members in a project
  • Manage project roles

• Project Integrations: This would allow syncs, dynamic secrets and third-party credentials to be contained within a project

• Project Roles: Project roles would allow for users to have a different role than their org role within the domain of a project. This would allow for a Developer at the org level to be a Project-Admin, for example.

• Project navigation

  • Projects list page at /org/projects
  • Project detail at /org/projects/<project_id>
    • Apps
    • Access
    • Integrations
    • Settings

---

Global Secrets

Global Secrets are secrets defined globally across a given scope of apps. They can take the form of:

• Organization secrets
• Project secrets

Global Secrets are automatically inherited by Apps within their scope. This allows for secrets or configurations that are shared by a set of Apps to be defined once and implicitly included where required.

Motivation

A common pattern when managing secrets in multi-application setups or monorepos is for a common set of configurations to be defined once, and application-specific secrets to be defined at a lower hierarchy. We've also seen requests for the ability to define "Org-level" secrets, that can be overridden by specific Apps if required. Currently this can be achieved in Phase by creating a 'common' or 'default' app, and using Secret Referencing to explicitly include their secrets in Apps and Envs where required.

However, this approach does not scale well as the number of secrets and apps grow. This approach also doesn't correctly represent the hierarchy which would allow for advanced use cases, such as application-level overrides of global secrets.

Implementation

Global Secrets will be implemented under the hood via a single designated 'Global App' within an Org / Project.

Global Apps will generally function identically to normal Apps, in that they have Environments with Secrets, but will have the following key differences:

• Secrets defined within Envs of the Global App are implicitly included in the respective Envs of Apps within their scope. For example:
  • Org has Global App global [dev, stag, prod]
  • Org has app api [dev, stag, prod]
  • Secrets deployed from api [dev] will include all secrets defined in global [dev]
• This will also apply for Projects. A Global App defined within a project will result in secrets deployed from Apps and Envs within the Project to include secrets from the respective env in the Global App.
• Access to global apps are locked to everyone within the scope, i.e the Org or Project
  • If an Org has a Global App -> All Org members and service accounts have fixed access to this Global App
  • If a Project has a Global App -> All Project members (members of apps within the Project) have access to this Global App

Configuration

• Org-wide setting to enable or disable global secret inheritance
• Project-wide setting to enable or disable global secret inheritance
• Projects can be configured to inherit or exclude Org-level global secrets
• App-level setting to enable or disable global secrets being inherited

[KahigaKiguru]

This is great, I love the idea.

You must also address a pressing problem - hierarchical dynamic secret syncing. Should a shared or cross-referenced secret in the org-level or project-level rotate, ensure that it cascades wherever said secrets are shipped (CI, K8s...) fast.

This is a problem many of us are keen to see fixed. The current situation is such that we must manually follow up across dependent apps and sync to ensure secrets are cascaded effectively.

Thank you for involving the community on this one @rohan-chaturvedi !