diff --git a/docs/documentation/getting-started/platform.mdx b/docs/documentation/getting-started/platform.mdx
index a21352a09..71394739c 100644
--- a/docs/documentation/getting-started/platform.mdx
+++ b/docs/documentation/getting-started/platform.mdx
@@ -2,21 +2,48 @@
title: "Platform"
---
-Infisical is an [open-source](https://opensource.com/resources/what-open-source), [end-to-end encrypted](https://en.wikipedia.org/wiki/End-to-end_encryption) secret management platform that enables teams to easily store, manage, and sync secrets like API keys, database credentials, and environment variables across their apps and infrastructure.
+Infisical is an [open-source](https://opensource.com/resources/what-open-source), [end-to-end encrypted](https://en.wikipedia.org/wiki/End-to-end_encryption) secret management platform that enables teams to easily store, manage, and sync
+application configuration and secrets like API keys, database credentials, and environment variables across applications and infrastructure.
+It also has secret scanning capabilities for detecting leaked secrets in codebases.
-This quickstart provides an overview of the functionalities offered by Infisical.
+This quickstart provides an overview of functionalities offered by Infisical.
-## Projects
+## Managing your Organization
-Projects hold secrets for applications, which are further organized into environments such as development, testing and production.
+When you first make an account with Infisical, you also create a new **organization** where you are assigned the `admin` role by default.
+From there, you can invite external members to the organization and start creating **projects** to house secrets.
+
+### Projects
+
+The **Projects** page shows you all the projects that you have access to within your organization.
+Here, you can also create a new project.
+
+
+
+### Members
+
+The **Members** page lets you add or remove external members to your organization.
+Note that you can configure your organization in Infisical to have members authenticate with the platform via protocols like SAML 2.0.
+
+
+
+## Managing your Projects
+
+As mentioned before, projects house secrets which are further organized into environments such as development, testing and production.
+A project can be anything from a single application to a collection of micro-services that you wish to manage secrets for.
### Secrets Overview
-The secrets overview provides a bird's-eye view of all the secrets in a project and is particularly useful for identifying missing secrets across environments.
+The **Secrets Overview** screen provides a bird's-eye view of all the secrets in a project and is useful for comparing secrets and identifying missing ones across environments.
-### Secrets Dashboard
+In the above image, you can already see that:
+- `STRIPE_API_KEY` is missing from the **Staging** environment.
+- `JWT_SECRET` is missing from the **Production** environment.
+- `BAR` is `EMPTY` in the **Production** environment.
+
+### Dashboard
The secrets dashboard lets you manage secrets for a specific environment in a project.
Here, developers can [override secrets](//project#personal-overrides), [version secrets](/documentation/platform/secret-versioning), [rollback projects to any point in time](/documentation/platform/pit-recovery), and much more.
@@ -35,23 +62,13 @@ The integrations page provides native integrations to sync secrets from a projec
-### Access Control
+### Members
-The members page lets you add/remove members for a project and provision them access to environments (access levels include `No Access`, `Read Only`, and `Read and Write`).
+The members page lets you add/remove members to/from a project and provision them access to environments via roles. By default, Infisical provides the `admin`, `developer`, and `viewer` roles
+which you can assign to members.
-## Organizations
-
-Organizations house projects and members.
-
-### Organization Settings
-
-At the organization-level, you can add/remove members and manage their access to projects.
-
-
-
-
That's it for the platform quickstart! — We encourage you to continue exploring the documentation to gain a deeper understanding of the extensive features and functionalities that Infisical has to offer.
Next, head back to [Getting Started > Introduction](/documentation/getting-started/overview) to explore ways to fetch secrets from Infisical to your apps and infrastructure.
\ No newline at end of file
diff --git a/docs/images/dashboard-secrets-overview.png b/docs/images/dashboard-secrets-overview.png
index 68b31de72..2d43e385e 100644
Binary files a/docs/images/dashboard-secrets-overview.png and b/docs/images/dashboard-secrets-overview.png differ
diff --git a/docs/images/dashboard.png b/docs/images/dashboard.png
index 2188debfc..506f0b0ed 100644
Binary files a/docs/images/dashboard.png and b/docs/images/dashboard.png differ
diff --git a/docs/images/organization-members.png b/docs/images/organization-members.png
index 90344b698..70190df0c 100644
Binary files a/docs/images/organization-members.png and b/docs/images/organization-members.png differ
diff --git a/docs/images/organization-overview.png b/docs/images/organization-overview.png
new file mode 100644
index 000000000..df4273b6f
Binary files /dev/null and b/docs/images/organization-overview.png differ
diff --git a/docs/images/project-members.png b/docs/images/project-members.png
index 87b2a7ee4..a166362de 100644
Binary files a/docs/images/project-members.png and b/docs/images/project-members.png differ
diff --git a/docs/integrations/cloud/vercel.mdx b/docs/integrations/cloud/vercel.mdx
index f756e4fe8..b7396d067 100644
--- a/docs/integrations/cloud/vercel.mdx
+++ b/docs/integrations/cloud/vercel.mdx
@@ -61,22 +61,23 @@ Select which Infisical environment secrets you want to sync to which Vercel app
- Create the application. As part of the form, set **Redirect URL** to `https://your-domain.com/integrations/vercel/oauth2/callback`. Also,
+ Create the application. As part of the form, set a **URL Slug** to a unique slug like `infisical-your-domain` and keep it handy. Also, set **Redirect URL** to `https://your-domain.com/integrations/vercel/oauth2/callback`. Lastly,
be sure to set the API Scopes according to the second screenshot below.
- ## Add your Vercel integration credentials to Infisical
+ ## Add your Vercel integration credentials and information to Infisical
- Obtain the **Client (Integration) ID** and **Client (Integration) Secret** for your Vercel integration.
+ Obtain the **Client (Integration) ID** and **Client (Integration) Secret** as well as the **URL Slug** from earlier for your Vercel integration.
- Back in your Infisical instance, add two new environment variables for the credentials of your Vercel integration.
+ Back in your Infisical instance, add three new environment variables for the credentials of your Vercel integration.
- `CLIENT_ID_VERCEL`: The **Client (Integration) ID** of your Vercel integration.
- `CLIENT_SECRET_VERCEL`: The **Client (Integration) Secret** of your Vercel integration.
+ - `CLIENT_SLUG_VERCEL`: The **URL Slug** of your Vercel integration.
Once added, restart your Infisical instance and use the Vercel integration.
diff --git a/docs/mint.json b/docs/mint.json
index 975687508..a83692fae 100644
--- a/docs/mint.json
+++ b/docs/mint.json
@@ -382,15 +382,6 @@
"internals/service-tokens"
]
},
- {
- "group": "Security",
- "pages": [
- "security/overview",
- "security/data-model",
- "security/mechanics",
- "security/service-tokens"
- ]
- },
{
"group": "Overview",
"pages": ["changelog/overview"]
diff --git a/docs/security/data-model.mdx b/docs/security/data-model.mdx
deleted file mode 100644
index af4adeb24..000000000
--- a/docs/security/data-model.mdx
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: "Data Model"
-description: "Infisical's current Data Structure."
----
-
-Infisical stores a range of data namely user, secrets, keys, organization, project, and membership data.
-
-## Users
-
-The `User` model includes the fields `email`, `firstName`, `lastName`, `publicKey`, `encryptionVersion`, `protectedKey`, `protectedKeyIV`, `protectedKeyTag`, `encryptedPrivateKey`, `iv`, `tag`, `salt`, `verifier`, and `refreshVersion`.
-
-Infisical makes a usability-security tradeoff that is to give users convenient access to public-private key pairs across different devices upon login, solving key-storage and transfer challenges across device and browser mediums, in exchange for it storing `encryptedPrivateKey`.
-
-
- `encryptedPrivateKey` is obtained by symmetrically encrypting the user's
- private key locally with a protected key which is encrypted by the key derived
- from the user's password and salt. Encryption is done via `AES256-GCM` and key
- derivation via `argon2id`. The user's password is not sent to the server —
- this is done with SRP.
-
-
-## Secrets
-
-The `Secret` model includes the fields `workspace`, `type`, `user`, `environment`, `secretBlindIndex`, `secretKeyCiphertext`, `secretKeyIV`, `secretKeyTag`, `secretValueCiphertext`, `secretValueIV`, and `secretValueTag`.
-
-Each secret consists of a key name and value pair and is symmetrically encrypted by the key of the project that it belongs to; that key's encrypted copies are stored in a separate `Key` collection.
-
-The `secretBlindIndex` enables users to query secrets by their names; it is a blind index computed by applying `argon2id` with a 128-bit random salt (unique to each project) and the name of the secret. The salt itself is symmetrically encrypted under the server key and stored in the `SecretBlindIndexData` collection.
-
-## Blind Index Data
-
-The `SecretBlindIndexData` model includes the fields `workspace`, `encryptedSaltCiphertext`, `saltIV`, and `saltTag`.
-
-Infisical stores salts (unique to each project) symmetrically encrypted under the server key. The salts are used to compute blind indices for secrets that enable
-users to query secrets by name.
-
-## Project Keys
-
-The `Key` model includes the fields `encryptedKey`, `nonce`, `sender`, `receiver`, and `workspace`.
-
-Infisical stores copies of project keys, one for each member of a project, asymmetrically encrypted under each member's public key.
-
-## Bots
-
-The `Bot` model contains the fields `name`, `workspace`, `isActive`, `publicKey`, `encryptedPrivateKey`, `iv`, and `tag`.
-
-Each project comes with a bot that has its own public-private key pair; its private key is symmetrically encrypted by the server's key. If needed, a user can opt-in to share their project key with the bot (i.e. Infisical) to give the platform access to the project's secrets.
-
-
- Sharing secrets with Infisical so they can be synced to integrations like
- Vercel, GitHub, and Netlify is something we make sure users consent to before
- opting in.
-
-
-## Organizations and Workspaces
-
-The `Organization`, `Workspace`, `MembershipOrg`, and `Membership` models contain enrollment information for organizations and projects; they are used to check if users are authorized to retrieve select secrets.
-
-## Service Tokens
-
-The `ServiceTokenData` model contains data for service tokens that enable users to fetch secrets from a particular project and environment; each service token data record includes an (encrypted) copy of the project key that it is bound to as well as a validation hash for `bcrypt`.
-
-## API Keys
-
-The `APIKeyData` model contains data for API keys that enable users to interact with [Infisical's Open API](https://infisical.com/docs/api-reference/overview/introduction); each API key data record includes a validation hash for `bcrypt`.
diff --git a/docs/security/mechanics.mdx b/docs/security/mechanics.mdx
deleted file mode 100644
index 06d5fedd9..000000000
--- a/docs/security/mechanics.mdx
+++ /dev/null
@@ -1,46 +0,0 @@
----
-title: "Mechanics"
-description: "Quick explanation of how Infisical works."
----
-
-## Signup
-
-During account signup, a user confirms their email address via OTP, generates a public-private key pair to be stored locally, generates a user salt, generates a 256-bit key, and enters their password.
-
-The 256-bit key is used to encrypt the private key; the 256-bit key itself is then encrypted by a key generated from the user's password and salt with key derivation function `argon2id`. The resulting, 256-bit key is known as the protected key.
-
-The encrypted private key, protected key, user identifier information, and SRP details are forwarded to the server.
-
-Once authenticated via SRP, a user is issued a JWT and refresh token. The JWT token is stored in browser memory and is appended to all future outbound requests requiring authentication. The refresh token is stored in an `HttpOnly` cookie and included in future requests to `/api/token` for JWT token renewal. This design side-steps potential XSS attacks on local storage.
-
-
- Infisical authenticates users using the SRP protocol. With SRP, the server can
- authenticate users without ever seeing their passwords.
-
-
-## Invitation
-
-After signing up, a user can invite other users to their organization to partake in projects — An invitation here consists of an email verification link sent to the invitee to confirm their identity if they've not previously signed up to Infisical. Both organization and project invites authorize invitees for resources but project invites differ in that they also involve sharing project keys by encrypting them under the invitees' public keys.
-
-## Pushing/Pulling Secrets
-
-To push secrets, a sender randomly-generates a symmetric encryption key, uses that key to encrypt their secret keys and values separately, asymmetrically encrypts the key with the receivers’ public keys, and uploads the encrypted secrets and keys to the server.
-
-To pull secrets, a receiver obtains encrypted secret keys and values and their encrypted copy of the project key to decrypt the secrets from the server — they asymmetrically decrypt the key using their private key and use the decrypted key to decrypt the secrets. This public-key mechanism prevents the server-side from reading any secrets.
-
-When dealing with individual secrets (e.g. pulling one secret by name) or creating new secrets, a user passes the name of the secret to the server which is then converted to a blind index by applying `argon2id` with the name of the secret and a 128-bit random salt unique to each project; the salt itself is encrypted by the server key and stored in the database.
-
-
- Infisical ensures that the name of any secret is never stored in plaintext and
- instead only a blind index generated from the name. It is infeasible to
- reverse back a blind index to the name of a secret without knowledge of the
- server key.
-
-
-## Bot
-
-To use some features like integrations, users must opt out of E2EE (this means sharing access to secrets with Infisical).
-
-Infisical employs the concept of a bot which is a cryptographic abstraction for how Infisical interacts with secrets when users opt out of E2EE. In this model, each project is assigned a bot with its own public-private key pair where each bot's private key is stored symmetrically encrypted under the server key. When a user opts out of E2EE, they share the project key with the bot by encrypting a copy of it under the public key of the bot.
-
-When users wish to sync secrets from a project and environment Infisical to other platform integrations like Vercel or GitHub, Infisical decrypts the intended secrets and uses the integration platform's APIs to send secrets over. It should be noted that opting out of E2EE is optional and it is entirely possible to use Infisical to manage secrets across your team and infrastructure without opting out of E2EE.
diff --git a/docs/security/overview.mdx b/docs/security/overview.mdx
deleted file mode 100644
index bd0ed0878..000000000
--- a/docs/security/overview.mdx
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title: "Overview"
-description: "Infisical's security statement."
----
-
-## Summary
-
-Infisical uses end-to-end encryption (E2EE) whenever possible to securely store and share secret values. It uses secure remote password (SRP) to handle authentication and public-key cryptography for secret sharing and syncing; secrets are symmetrically encrypted by keys decryptable only by members of the project.
-
-Infisical uses AES256-GCM for symmetric encryption and x25519-xsalsa20-poly1305 for asymmetric encryption operations mentioned in this brief; key generation and asymmetric algorithms are implemented with the [TweetNaCl.js](https://tweetnacl.js.org/#/) library which has been well-audited and recommended for use by cybersecurity firm Cure53. Lastly, the secure remote password (SRP) implementation uses [jsrp](https://github.com/alax/jsrp) package for user authentication.
-
-As part of our commitment to user privacy and security, we undergo penetration tests twice a year and are working to achieve SOC 2 (Type II) compliance in Fall 2023.
-
-## Scope
-
-Infisical's security model spans sensitive data stored on the server-side and in transit between user devices; it makes no security guarantees for malicious events that can occur beyond its control such as user-device security exploits or key-logging arising from poor cybersecurity management on the users’ behalf.
-
-## Lingo
-
-In subsequent sections, we refer:
-
-- To users uploading their secrets to Infisical as “senders” and those receiving secrets as “receivers". For instance, if Bob and Alice are both enrolled in a project and Bob adds new secrets to the project to be pulled by Alice, then Bob is considered to be the sender and Alice the receiver.
-- To any activity involving uploading or modifying secrets to Infisical as "pushing" and fetching secrets from Infisical as "pulling."
-
-## Statement
-
-As a secrets manager, we are deeply committed to enforcing the privacy and security of all users and data on the platform but acknowledge that it is virtually impossible to guarantee perfect security; unfortunately, even the most secure systems have vulnerabilities.
-
-As part of our commitment, we do our best to maintain platform privacy and security, notify users if anything goes wrong, and rectify adverse situations immediately if anything happens.
-We are continuously adding more opt-in security measures to ensure better data protection and maintain trust within the growing community. With that, let’s make the most simple and secure secrets management system out there!
-
-Best,
-
-Infisical Team
diff --git a/docs/security/service-tokens.mdx b/docs/security/service-tokens.mdx
deleted file mode 100644
index b70f527eb..000000000
--- a/docs/security/service-tokens.mdx
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: "Service Tokens"
-description: "Understanding service tokens and their best practices"
----
-
-## Background
-
-Many clients use service tokens to authenticate and read/write secrets from/to Infisical.
-
-Each service token consist of two parts used for authentication and decryption, separated by `.`. Consider the token `st.abc.def.ghi`. Here, `st.abc.def` can be used to authenticate with the API, by including it in the `Authorization` header under `Bearer st.abc.def`, and retrieve (encrypted) secrets as well as a project key back. Meanwhile, `ghi`, a hex-string, can be used to decrypt the project key used to decrypt the secrets.
-
-Note that when using service tokens via select client methods like SDK or CLI, cryptographic operations are abstracted for you that is the token is parsed and encryption/decryption operations are handled. If using service tokens with the REST API and end-to-end encryption enabled, then you will have to handle the encryption/decryption operations yourself.
-
-## Recommendations
-
-1. Issuance: When creating a new service token, it’s important to consider the [principle of least privilege(PoLP)](https://en.wikipedia.org/wiki/Principle_of_least_privilege) when setting its scope and expiration date. For example, if the client using the token only requires access to a staging environment, then you should scope the token to that environment only; you can further scope tokens to path(s) within environment(s) if you happen to use [path-based secret storage](/documentation/platform/folder). Likewise, if the client does not intend to access secrets indefinitely, then you may consider setting a finite lifetime for the token such as 6 months or 1 year from now. Finally, you should consider carefully whether or not your client requires the ability to read and/or write secrets from/to Infisical.
-
-2. Network access: We recommend configuring the IP whitelist settings of each project to allow either single IP addresses or CIDR-notated range of addresses to read/write secrets to Infisical. With this feature, you can specify the IP range of your client servers to restrict access to your project in Infisical.
-
-3. Storage: Since service tokens grant access to your secrets, we recommend storing service tokens securely across your development cycle whether it be in a `.env` file in local development or as an environment variable of your deployment platform.
-
-4. Rotation: We recommend periodically rotating the service token, even in the absence of compromise. Since service tokens are capable of decrypting project keys used to decrypt secrets, all of which use AES-256-GCM encryption, they should be rotated before approximately 2^32 encryptions have been performed; this follows the guidance set forth by NIST publication 800-38D. Note that Infisical keeps track of the number of times that service tokens are used and will alert you when you have reached 90% of the recommended capacity.