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

docs/changelog/overview.mdx

@@ -4,16 +4,34 @@ title: "Changelog"
 
 The changelog below reflects new product developments and updates on a monthly basis.
 
-## September
+## November 2023
 
+- Replaced internal [Winston](https://github.com/winstonjs/winston) with [Pino](https://github.com/pinojs/pino) logging library with external logging to AWS CloudWatch
+- Added admin panel to self-hosting experience.
+- Released [secret rotation](https://infisical.com/docs/documentation/platform/secret-rotation/overview) feature with preliminary support for rotating [SendGrid](https://infisical.com/docs/documentation/platform/secret-rotation/sendgrid), [PostgreSQL/CockroachDB](https://infisical.com/docs/documentation/platform/secret-rotation/postgres), and [MySQL/MariaDB](https://infisical.com/docs/documentation/platform/secret-rotation/mysql) credentials.
+- Released secret reminders feature.
+
+## October 2023
+
+- Added support for [GitLab SSO](https://infisical.com/docs/documentation/platform/sso/gitlab).
+- Became SOC 2 (Type II) certified.
+- Reduced required JWT configuration from 5-6 secrets to 1 secret for self-hosting Infisical.
+- Compacted Infisical into 1 Docker image.
+- Added native [Hasura Cloud integration](https://infisical.com/docs/integrations/cloud/hasura-cloud).
+- Updated resource deletion logic for user, organization, and project deletion.
+
+## September 2023
+
+- Released [secret approvals](https://infisical.com/docs/documentation/platform/pr-workflows) feature.
 - Released an update to access controls; every user role now clearly defines and enforces a certain set of conditions across Infisical.
 - Updated UI/UX for integrations. 
 - Added a native integration with [Qovery](https://infisical.com/docs/integrations/cloud/qovery).
+- Added service token generation capability for the CLI.
 
 ## August 2023
 
 - Release Audit Logs V2.
-- Add support for GitHub SSO.
+- Add support for [GitHub SSO](https://infisical.com/docs/documentation/platform/sso/github).
 - Enable users to opt in for multiple authentication methods.
 - Improved password requirements including check against [Have I Been Pwnd Password API](https://haveibeenpwned.com/Passwords).
 - Added native [GCP Secret Manager integration](https://infisical.com/docs/integrations/cloud/gcp-secret-manager)
@@ -31,8 +49,8 @@ The changelog below reflects new product developments and updates on a monthly b
 - Added native [Terraform Cloud integration](https://infisical.com/docs/integrations/cloud/terraform-cloud).
 - Added native [Northflank integration](https://infisical.com/docs/integrations/cloud/northflank).
 - Added native [Windmill integration](https://infisical.com/docs/integrations/cloud/windmill).
-- Added support for Google SSO.
-- Added support for [Okta](https://infisical.com/docs/documentation/platform/sso/okta), [Azure AD](https://infisical.com/docs/documentation/platform/sso/azure), and JumpCloud [SAML](https://infisical.com/docs/documentation/platform/saml) authentication.
+- Added support for [Google SSO](https://infisical.com/docs/documentation/platform/sso/google)
+- Added support for [Okta](https://infisical.com/docs/documentation/platform/sso/okta), [Azure AD](https://infisical.com/docs/documentation/platform/sso/azure), and [JumpCloud](https://infisical.com/docs/documentation/platform/sso/jumpcloud) [SAML](https://infisical.com/docs/documentation/platform/saml) authentication.
 - Released [folders / path-based secret storage](https://infisical.com/docs/documentation/platform/folder).
 - Released [webhooks](https://infisical.com/docs/documentation/platform/webhooks).
 

docs/contributing/code-of-conduct.mdx

@@ -63,7 +63,7 @@ representative at an online or offline event.
 
 Instances of abusive, harassing, or otherwise unacceptable behavior may be
 reported to the community leaders responsible for enforcement at
-[INSERT CONTACT METHOD].
+[email protected].
 All complaints will be reviewed and investigated promptly and fairly.
 
 All community leaders are obligated to respect the privacy and security of the

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)

docs/infisical-agent/overview.mdx

@@ -0,0 +1,93 @@
+---
+title: "Infisical Agent"
+---
+
+Infisical Agent is a client daemon that simplifies the adoption of Infisical by providing a more scalable and user-friendly approach for applications to interact with Infisical.
+It eliminates the need to modify application logic by enabling clients to decide how they want their secrets rendered through the use of templates.
+
+<img height="200" src="../images/agent/infisical-agent-diagram.png" />
+
+### Key features:
+- Token renewal: Automatically authenticates with Infisical and deposits renewed access tokens at specified path for applications to consume
+- Templating: Renders secrets via user provided templates to desired formats for applications to consume
+
+### Token renewal
+The Infisical agent can help manage the life cycle of access tokens. The token renewal process is split into two main components: a Method, which is the authentication process suitable for your current setup, and Sinks, which are the places where the agent deposits the new access token whenever it receives updates.
+
+When the Infisical Agent is started, it will attempt to obtain a valid access token using the authentication method you have configured. If the agent is unable to fetch a valid token, the agent will keep trying, increasing the time between each attempt. 
+
+Once a access token is successfully fetched, the agent will make sure the access token stays valid, continuing to renew it before it expires.
+
+Every time the agent successfully retrieves a new access token, it writes the new token to the Sinks you've configured.
+
+<Info>
+  Access tokens can be utilized with Infisical SDKs or directly in API requests to retrieve secrets from Infisical
+</Info>
+
+### Templating
+The Infisical agent can help deliver formatted secrets to your application in a variety of environments. To achieve this, the agent will retrieve secrets from Infisical, format them using a specified template, and then save these formatted secrets to a designated file path. 
+
+Templating process is done through the use of Go language's [text/template feature](https://pkg.go.dev/text/template). Multiple template definitions can be set in the agent configuration file to generate a variety of formatted secret files.
+
+When the agent is started and templates are defined in the agent configuration file, the agent will attempt to acquire a valid access token using the set authentication method outlined in the agent's configuration. 
+If this initial attempt is unsuccessful, the agent will momentarily pauses before continuing to make more attempts.
+
+Once the agent successfully obtains a valid access token, the agent proceeds to fetch the secrets from Infisical using it. 
+It then formats these secrets using the user provided templates and writes the formatted data to configured file paths.
+
+## Agent configuration file 
+
+To set up the authentication method for token renewal and to define secret templates, the Infisical agent requires a YAML configuration file containing properties defined below. 
+While specifying an authentication method is mandatory to start the agent, configuring sinks and secret templates are optional.
+
+| Field                        | Description |
+| ---------------------------- | ----------- |
+| `infisical.address`          | The URL of the Infisical service. Default: `"https://app.infisical.com"`. |
+| `auth.type`                  | The type of authentication method used. Only `"token"` type is currently available |
+| `auth.config.token-path`     | The file path where the initial token for authentication is stored.  |
+| `sinks[].type`               | The type of sink in a list of sinks. Each item specifies a sink type. Currently, only `"file"` type is available. |
+| `sinks[].config.path`        | The file path where the access token should be stored for each sink in the list. |
+| `templates[].source-path`    | The path to the template file that should be used to render secrets. |
+| `templates[].destination-path` | The path where the rendered secrets from the source template will be saved to. |
+
+
+## Quick start Infisical Agent
+To install the Infisical agent, you must first install the [Infisical CLI](../cli/overview) in the desired environment where you'd like the agent to run. This is because the Infisical agent is a sub-command of the Infisical CLI.
+
+Once you have the CLI installed, you will need to create a agent configuration file in yaml. 
+
+```yaml example-agent-config-file.yaml
+infisical:
+  address: "https://app.infisical.com"
+auth:
+  type: "token"
+  config:
+    token-path: "/path/to/initial/token"
+sinks:
+  - type: "file"
+    config:
+      path: "/some/path/to/store/access-token/file-name"
+templates:
+  - source-path: my-dot-ev-secret-template
+    destination-path: /some/path/.env
+```
+
+Above is an example agent configuration file that defines the token authentication method, one sink location (where to deposit access tokens after renewal) and a secret template. 
+
+
+```text my-dot-ev-secret-template
+{{- with secret "6553ccb2b7da580d7f6e7260" "dev" "/" }}
+{{- range . }}
+{{ .Key }}={{ .Value }}
+{{- end }}
+{{- end }}
+```
+
+The secret template above will be used to render the secrets where the key and the value are separated by `=` sign. You'll notice that a custom function named `secret` is used to fetch the secrets. 
+This function takes the following arguments: `secret "<project-id>" "<environment-slug>" "<secret-path>"`. 
+
+```bash 
+infisical agent --config example-agent-config-file.yaml
+```
+
+After defining the agent configuration file, run the command above pointing to the path where the agent configuration is located. 

docs/internals/security.mdx

@@ -135,7 +135,7 @@ Lastly, Infisical enforces strong password requirements according to the guidanc
 
 ## Role-based access control (RBAC)
 
-Infisical's RBAC feature enables organization owners and administrators to manage fine-grained access policies for members of their organization in Infisical; with RBAC, administrators can define custom roles with permission sets to be conveniently assigned to other members.
+[Infisical's RBAC](https://infisical.com/docs/documentation/platform/role-based-access-controls) feature enables organization owners and administrators to manage fine-grained access policies for members of their organization in Infisical; with RBAC, administrators can define custom roles with permission sets to be conveniently assigned to other members.
 
 For example, you can define a role provisioning access to secrets in a specific project and environment in it with read-only permissions; the role can be assigned to members of an organization in Infisical.
 

docs/mint.json

@@ -120,6 +120,8 @@
         "documentation/platform/token",
         "documentation/platform/machine-identity",
         "documentation/platform/mfa",
+        "documentation/platform/pr-workflows",
+        "documentation/platform/role-based-access-controls",
         {
           "group": "Secret Rotation",
           "pages": [
@@ -196,6 +198,12 @@
         "cli/faq"
       ]
     },
+    {
+      "group": "Agent",
+      "pages": [
+        "infisical-agent/overview"
+      ]
+    },
     {
       "group": "Integrations",
       "pages": ["integrations/overview"]

docs/self-hosting/deployment-options/standalone-infisical.mdx

@@ -39,7 +39,7 @@ Other configs can be found [here](../configuration/envars)
 </ParamField>
 
 <ParamField query="REDIS_URL" type="string" default="none">
-  Redis connection string. Only required if you plan to use web integrations.
+  Redis connection string. Only required if you plan to use web integrations or secret reminders.
 </ParamField>