Merge remote-tracking branch 'origin' into stv3-org-roles

docs/documentation/platform/pr-workflows.mdx

@@ -0,0 +1,33 @@
+---
+title: "PR Workflows"
+description: "Infisical PR Workflows allows you to create a set of policies to control secret operations."
+---
+
+## Problem at hand
+
+Updating secrets in high-stakes environments (e.g., production) can have a number of problematic issues: 
+- Most developers should not have access to secrets in production environments. Yet, they are the ones who often need to add new secrets or change the existing ones. Many organizations have in-house policies with regards to what person should be contacted in the case of needing to make changes to secrets. This slows down software development lifecycle and distracts engineers from working on things that matter the most.   
+- As a general rule, before making changes in production environments, those changes have to be looked over by at least another person. An extra pair of eyes can help reduce the risk of human error and make sure that the change will not affect the application in an unintended way. 
+- After making updates to secrets, the corresponding applications need to be redeployed with the right set of secrets and configurations. This process is often not automated and hence prone to human error. 
+
+## Solution
+
+As a wide-spread software engineering practice, developers have to submit their code as a PR that needs to be approved before the code is merged into the main branch. 
+
+In a similar way, to solve the above-mentioned issues, Infisical provides a feature called `PR Workflows` for secret management. This is a set of policies and workflows that help advance access controls, compliance procedures, and stability of a particular environment. In other words, **PR Workflows** help you secure, stabilize, and streamline the change of secrets in high-stakes environments. 
+
+### Setting a policy
+
+First, you would need to create a set of policies for a certain environment. In the example below you can see a generic policy for a production environment. In this case, any user who submits a change to `prod` would first have to get an approval by a predefined user (or multiple users).
+
+![create secret update policy](../../images/platform/pr-workflows/secret-update-policy.png)
+
+### Example of updating secrets with PR workflows
+
+When a user submits a change to an enviropnment that is under a particular policy, a corresponsing change request will go to a predefined approver (or multiple approvers). 
+
+![secret update change requests](../../images/platform/pr-workflows/secret-update-request.png)
+
+An approver is notified by email and/or Slack as soon as the request is initiated. In the Infisical Dashboard, they will be able to `approve` and `merge` (or `deny`) a request for a change in a particular environment. After that, depending on the workflows setup, the change will be automatically propagated to the right applications (e.g., using [Infisical Kubernetes Operator](https://infisical.com/docs/integrations/platforms/kubernetes)).
+
+![secrets update pull request](../../images/platform/pr-workflows/secret-update-pr.png)

docs/documentation/platform/role-based-access-controls.mdx

@@ -0,0 +1,31 @@
+---
+title: "Role-based Access Controls"
+description: "Infisical's Role-based Acccess Controls enable creating permissions for user and machine identities to restrict access to resources and the range of actions that can performed."
+---
+
+### General access controls
+
+Access Control Policies provide a highly granular declarative way to grant or forbid access to certain resources and operations in Infisical. In general, access controls can be split up across projects and organizations.
+
+### Organization-level access controls
+
+By default, every user in a organization is either an **admin** or a **member**. 
+
+Admins are able to perform every action with the organization, including adding and removing organization members, managing access controls, setting up security settings, and creating new projects. Members, on the other hand, are restricted from removing organization members, modifying billing information, updating access controls, and performing a number of other actions. 
+
+Overall, organization-level access controls are significantly of administrative nature. Access to projects, secrets and other sensitive data is specified on the project level. 
+
+![Org member role](../../images/platform/rbac/org-member-role.png)
+
+### Project-level access controls
+
+By default, every user in a project is either a **viewer**, **developer**, or an **admin**. Each of these roles comes with a varying access to different features and resources inside projects. As such, **admins** by default have access to all environments, folders, secrets, and actions within the project. At the same time, **developers** are restricted from performing project control actions, updating PR Workflow policies, managing roles/members, and more. Lastly, **viewer** is the most limiting default role on the project level – it forbids developers to perform any action and rather shows them in the read-only mode. 
+
+### Creating custom roles
+
+By creating custom roles, you are able to adjust permissions to the needs of your organization. This can be useful for: 
+- Creating superadmin roles, roles specific to SRE engineers, etc. 
+- Restricting access of users to specific secrets, folders, and environments. 
+- Embedding these specific roles into [PR Workflow policies](https://infisical.com/docs/documentation/platform/pr-workflows)
+
+![project member custom role](../../images/platform/rbac/project-member-custom-role.png)