Recently, we launched workspace approval workflows and the ability for a workspace owner to designate a set of approvers for that workspace. Building on this foundation, we plan to deliver a much more fine-grained approval workflow. This post will fill you in on the details, and you can always watch the readout of the opportunity on YouTube.

If this is your first exposure to how we communicate about the ongoing development of System Initiative, welcome! On our docs site, you can learn more about what opportunities are and how we work on System Initiative. You will also find our vocabulary page useful.

Fine-grained access control for the enterprise

When enterprises must comply with regulations such as ISO 27001, SOC 2, HIPAA, or GDPR, fine-grained access control is crucial in demonstrating compliance. It helps ensure access is appropriately restricted and monitored, providing auditors with clear evidence of control. Traditionally, practices like enforcing segregation of duties, limiting who can deploy or modify specific infrastructure, and adhering to the principle of least privilege, where users and systems have access only to the resources they require. To achieve this, teams often split their infrastructure-as-code across multiple source control repositories, limit who can change those repositories, or implement custom ticket-based approval workflows aligned with a Change Advisory Board’s requirements.

This opportunity empowers teams to seamlessly integrate best practices into their usage of System Initiative by enabling much more fine-grained access control for approving changes. We believe that implementing these changes will deliver three key benefits to users:

1. Enhanced Security and Risk Mitigation Fine-grained access control ensures that only authorized individuals can approve changes, reducing the likelihood of accidental or malicious actions. This helps safeguard critical systems and data, minimizing security vulnerabilities and operational risks.
2. Simplified Regulatory Compliance With built-in controls for managing access and approval processes, meeting regulatory requirements like ISO 27001, SOC 2, HIPAA, and GDPR becomes more straightforward.
3. Increased Operational Efficiency Streamlined and automated access control processes eliminate the need for manual oversight or cumbersome approval workflows. This allows teams to focus on their core tasks, accelerating delivery cycles and reducing overhead.

Our implementation plan is as follows:

• Add the ability to attach approvers to a view
• Approvers for a view are more fine-grained than approvers for a workspace and will take precedence
• We will calculate the full list of approvers required to approve before a change set is merged
  • This calculation will determine what components (or actions) have been acted upon and in what views they would require approval
• Changes to functions, schema variants, bindings, etc will require approval by a workspace-level approver
• All changes to view permissions will require approval by a workspace-level approver
• If an approval has been granted and subsequent changes have been made, then the approval is dismissed and will be required again.

An example scenario

John owns the workspace and has designated Brit as a workspace approver. The workspace contains two views:

• Networking view, which has Scott as an approver.
• DNS view, which does not have a specific approver.

A collaborator in the workspace performs the following tasks:

1. Creates a new asset called application.
2. Changes the tags on the tailscale instance (this belongs to the Networking view).
3. Adds a new view called Application Infrastructure and assigns themselves (Nick) as an approver for that view.
4. Adds a new entry to the Route53 zone for the application load balancer’s domain name.

Approval Logic

When the collaborator requests approval to merge the change set:

1. John or Brit will be required to approve:
   • Because there are changes to non-component items (e.g., the creation of a new asset and a new view).
   • Changes to view permissions (e.g., adding Nick as an approver for the Application Infrastructure view) require workspace-level approval.
2. Scott will be required to approve:
   • Because the tags on the tailscale instance were changed, which falls under the Networking view, where Scott is the designated approver.

Approval Requirement

For the merge to proceed:

• Both workspace-level approval (John or Brit) and view-level approval (Scott) are required.
• The condition is: (John or Brit) AND Scott must approve.

When can I expect this to land?

This opportunity has a budget of four weeks, ending January 24th, 2025. You can follow along with our progress by watching our weekly demos, posted every Monday on Discord, YouTube, and our Changelog. You can always find this, and every other active opportunity, in our Road map.