mirror of
https://github.com/awatertrevi/infisical.git
synced 2026-09-22 13:39:35 +00:00
Merge pull request #4301 from Infisical/docs-product-split
Update docs to be multi-product
This commit is contained in:
Maidul Islam
@@ -5,18 +5,19 @@ description: "Read more about the concept of user identities in Infisical."
|
||||
|
||||
## Concept
|
||||
|
||||
A **user identity** (also known as **user**) represents a developer, admin, or any other human entity interacting with resources in Infisical.
|
||||
A **user identity** (also known as **user**) represents a developer, admin, or any other human entity interacting with resources in Infisical.
|
||||
|
||||
Users can be added manually (through Web UI) or programmatically (e.g., API) to [organizations](../organization) and [projects](../projects).
|
||||
Users can be added manually (through Web UI) or programmatically (e.g., API) to [organizations](../organization) and [projects](../projects).
|
||||
|
||||
Upon being added to an organization and projects, users assume a certain set of roles and permissions that represents their identity.
|
||||
Upon being added to an organization and projects, users assume a certain set of roles and permissions that represents their identity.
|
||||
|
||||
|
||||
|
||||
|
||||
## Authentication methods
|
||||
|
||||
To interact with various resources in Infisical, users are able to utilize a number of authentication methods:
|
||||
- **Email & Password**: the most common authentication method that is used for authentication into Web Dashboard and Infisical CLI. It is recommended to utilize [Multi-factor Authentication](/documentation/platform/mfa) in addition to it.
|
||||
- **SSO**: Infisical natively integrates with a number of SSO identity providers like [Google](/documentation/platform/sso/google), [GitHub](/documentation/platform/sso/github), and [GitLab](/documentation/platform/sso/gitlab).
|
||||
- **SAML SSO**: It is also possible to set up SAML SSO integration with identity providers like [Okta](/documentation/platform/sso/okta), [Microsoft Entra ID](/documentation/platform/sso/azure) (formerly known as Azure AD), [JumpCloud](/documentation/platform/sso/jumpcloud), [Google](/documentation/platform/sso/google-saml), and more.
|
||||
To interact with various resources in Infisical, users are able to utilize a number of authentication methods:
|
||||
|
||||
- **Email & Password**: the most common authentication method that is used for authentication into Web Dashboard and Infisical CLI. It is recommended to utilize [Multi-factor Authentication](/documentation/platform/mfa) in addition to it.
|
||||
- **SSO**: Infisical natively integrates with a number of SSO identity providers like [Google](/documentation/platform/sso/google), [GitHub](/documentation/platform/sso/github), and [GitLab](/documentation/platform/sso/gitlab).
|
||||
- **SAML SSO**: It is also possible to set up SAML SSO integration with identity providers like [Okta](/documentation/platform/sso/okta), [Microsoft Entra ID](/documentation/platform/sso/azure) (formerly known as Azure AD), [JumpCloud](/documentation/platform/sso/jumpcloud), [Google](/documentation/platform/sso/google-saml), and more.
|
||||
- **LDAP**: For organizations with more advanced needs, Infisical also provides user authentication with [LDAP](/documentation/platform/ldap/overview) that includes a number of LDAP providers.
|
||||
|
||||
@@ -3,74 +3,94 @@ title: "Organizations"
|
||||
description: "Learn more and understand the concept of Infisical organizations."
|
||||
---
|
||||
|
||||
An Infisical organization is a set of [projects](./project) that use the same billing. Organizations allow one or more users to control billing and project permissions for all of the projects belonging to the organization. Each project belongs to an organization.
|
||||
Infisical is structured around organizations and [projects](/documentation/platform/project).
|
||||
|
||||
## Organizations
|
||||
|
||||
An organization represents a company or high-level entity (e.g. Acme Corp) and acts as the root scope for managing members and machine identities, projects, usage and billing, global integrations and configuration (such as single sign-on, provisioning, etc), and more.
|
||||
|
||||
Within an organization, you can create any number of projects—each tied to a specific product type such as Secrets Management or PKI that determines the functionality available.
|
||||
|
||||
|
||||
|
||||
## Projects
|
||||
|
||||
The **Projects** page is where you can view the projects that you have access to within your organization
|
||||
as well as create a new project.
|
||||
The _Projects_ tab shows a list of projects that you have access to.
|
||||
|
||||
|
||||
If you're an organization admin, you also have the option to view _All Projects_—a complete view of every project within the organization, including those you are not currently a member of— and gain access to any project.
|
||||
|
||||
## Settings
|
||||
Admins can gain access to any project in the organization by opening the options menu (⋮) next to a project and selecting Access. This will add you to the project as an admin and allow full visibility and control.
|
||||
|
||||
The **Settings** page lets you manage information about your organization including:
|
||||
|
||||
|
||||
- **Name**: The name of your organization.
|
||||
- **Slug**: The slug of your organization.
|
||||
- **Default Organization Member Role**: The role assigned to users when joining your organization unless otherwise specified.
|
||||
- **Incident Contacts**: Emails that should be alerted if anything abnormal is detected within the organization.
|
||||
- **Enabled Products**: Products which are enabled for your organization. This setting strictly affects the sidebar UI; disabling a product does not disable its API or routes.
|
||||
## Roles and Access Control
|
||||
|
||||
|
||||
The _Access Control_ tab lets you view and manage roles and permissions for users, machine identities, and groups across your organization.
|
||||
|
||||
- Security and Authentication: A set of setting to enforce or manage [SAML](/documentation/platform/sso/overview), [OIDC](/documentation/platform/sso/overview), [SCIM](/documentation/platform/scim/overview), [LDAP](/documentation/platform/ldap/overview), and other authentication configurations.
|
||||
Users are invited to an organization and assigned organization-level roles such as `Admin` or `Member`. You can also define [custom roles](/documentation/platform/access-controls/role-based-access-controls#creating-custom-roles) at the organization level to fit your permission model.
|
||||
|
||||
|
||||
|
||||
|
||||
<Tip>
|
||||
You can adjust the maximum time a user token will remain valid for your organization. After this period, users will be required to re-authenticate. This helps improve security by enforcing regular sign-ins.
|
||||
</Tip>
|
||||
Infisical supports [user identities](/documentation/platform/identities/user-identities) (representing people) and [machine identities](/documentation/platform/identities/machine-identities) (representing services, CI/CD pipelines, or agents). The same roles and permissions can be applied to either type of identity.
|
||||
|
||||
## Access Control
|
||||
To manage access at scale, Infisical also supports [user groups](/documentation/platform/groups) — roles assigned to a group apply to all of its members automatically.
|
||||
|
||||
The **Access Control** page is where you can manage identities (both people and machines) that are part of your organization.
|
||||
You can add or remove additional members as well as modify their permissions.
|
||||
Note that Infisical distinguishes between organization-level and project-level access control:
|
||||
|
||||
|
||||
|
||||
- [Organization-level access control](/documentation/platform/access-controls/role-based-access-controls#organization-level-access-controls): Roles and permissions governing access to organization-level resources and controls such as billing, member management, and identity provider configuration.
|
||||
- [Project-level access control](/documentation/platform/access-controls/role-based-access-controls#project-level-access-controls): Roles and permissions governing access to resources and workflows within a specific project (e.g., secrets, certificates, SSH hosts).
|
||||
|
||||
In the **Organization Roles** tab, you can edit current or create new custom roles for members within the organization.
|
||||
|
||||
|
||||
To learn more about how permissions work in detail, refer to the [access control documentation](/documentation/platform/access-controls/overview).
|
||||
|
||||
<Info>
|
||||
Note that Role-Based Access Management (RBAC) is partly a paid feature.
|
||||
|
||||
Infisical provides immutable roles like `admin`, `member`, etc.
|
||||
at the organization and project level for free.
|
||||
Infisical provides immutable roles such as `admin` and `member` for free.
|
||||
|
||||
If you're using Infisical Cloud, the ability to create custom roles is available under the **Pro Tier**.
|
||||
|
||||
If you're self-hosting Infisical, then you should contact sales@infisical.com to purchase an enterprise license to use it.
|
||||
|
||||
</Info>
|
||||
|
||||
|
||||
|
||||
As you can see next, Infisical supports granular permissions that you can tailor to each role.
|
||||
If you need certain members to only be able to access billing details, for example, then you can
|
||||
assign them that permission only.
|
||||
|
||||
|
||||
|
||||
## Usage & Billing
|
||||
|
||||
The **Usage & Billing** page applies only to [Infisical Cloud](https://app.infisical.com) and is where you can
|
||||
manage your plan and billing information.
|
||||
The _Usage & Billing_ tab provides an overview of your organization's billing information and platform usage.
|
||||
|
||||
This includes the following items:
|
||||
Infisical calculates usage at the organization level—aggregating activity across all projects and product types (e.g., Secrets Management, SSH, PKI). From this tab, you can track usage, view billing details, and manage your Infisical Cloud subscription.
|
||||
|
||||
- Current plan: The current plan information such as what tier your organization is on and what features/limits apply to this tier.
|
||||
- Licenses: The license keys for self-hosted instances of Infisical (if applicable).
|
||||
- Receipts: The receipts of monthly/annual invoices.
|
||||
- Billing: The billing details of your organization including payment methods on file, tax IDs (if applicable), etc.
|
||||
|
||||
|
||||
|
||||
## Audit Logs
|
||||
|
||||
Infisical provides a unified view of [audit logs](/documentation/platform/audit-logs) at the organization level. All platform activity—including secret access, certificate issuance, platform logins across the organization —is recorded and searchable in a central log view.
|
||||
|
||||
Audit logs are also viewable at the project level, where they are scoped to show only events relevant to that specific project. This allows project administrators to monitor activity and investigate changes without requiring organization-wide access.
|
||||
|
||||
## App Connections
|
||||
|
||||
Infisical supports [app connections](/integrations/app-connections/overview) — integrations configured at the organization level with third-party platforms such as AWS, GCP, GitHub, and many others.
|
||||
|
||||
Once configured, these connections can be reused across multiple projects as part of any feature that requires third-party integrations—such as [secret syncing](/integrations/secret-syncs/overview) or [dynamic credential generation](/documentation/platform/dynamic-secrets/overview).
|
||||
|
||||
|
||||
|
||||
To learn more, refer to the [app connections documentation](/integrations/app-connections/overview).
|
||||
|
||||
## Organization Settings
|
||||
|
||||
The _Organization Settings_ tab lets you configure global behavior and security controls for the organization.
|
||||
|
||||
Key configuration areas include:
|
||||
|
||||
- General: Manage the organization’s name, slug, and default role for newly invited members.
|
||||
- Single Sign-On (SSO): Enable [SAML](/documentation/platform/sso/overview), [LDAP](/documentation/platform/ldap/overview), or [OIDC-based](/documentation/platform/sso/general-oidc/overview) authentication for user login.
|
||||
- Provisioning: Enable [SCIM](/documentation/platform/scim/overview) to automatically provision and deprovision users and groups from an identity provider.
|
||||
- Security Policies: Enforce MFA and configure session duration limits.
|
||||
- Encryption: Integrate with external KMS systems or bring your own encryption keys (BYOK).
|
||||
- [Audit Log Streaming](/documentation/platform/audit-log-streams/audit-log-streams): Forward audit events to third-party logging tools like SIEMs or cloud storage.
|
||||
- Workflow Integrations: Trigger [Slack](/documentation/platform/workflow-integrations/slack-integration) or [Microsoft Teams](/documentation/platform/workflow-integrations/microsoft-teams-integration) notifications for events like access requests.
|
||||
- [Project Templates](/documentation/platform/project-templates): Define default environments, roles, and settings to standardize project creation.
|
||||
- KMIP (Enterprise): Connect to KMIP-compatible HSMs for hardware-backed key storage and operations.
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
title: "Internal PKI"
|
||||
title: "Infisical PKI"
|
||||
sidebarTitle: "Overview"
|
||||
description: "Learn how to create a Private CA hierarchy and issue X.509 certificates."
|
||||
---
|
||||
|
||||
Infisical can be used to create a Private Certificate Authority (CA) hierarchy and issue X.509 certificates for internal use. This allows you to manage your own PKI infrastructure and issue digital certificates for subscribers such as services, applications, and devices.
|
||||
Infisical can be used to create and manage Certificate Authorities (CAs) and issue X.509 certificates. This allows you to manage PKI infrastructure and issue digital certificates for subscribers such as services, applications, and devices.
|
||||
|
||||
Infisical's PKI offering is split into three components:
|
||||
|
||||
- [Certificate Authorities](/documentation/platform/pki/private-ca): Create and manage private CAs, including root and intermediate CAs.
|
||||
- [Certificate Authorities](/documentation/platform/pki/private-ca): Create and manage CAs, including root and intermediate CAs.
|
||||
- [Subscribers](/documentation/platform/pki/subscribers): Define and manage entities that will request X.509 certificates from CAs. This module provides a centralized view of all subscribers, enabling you to issue certificates and monitor their status.
|
||||
- [Certificates](/documentation/platform/pki/certificates): Track and monitor issued X.509 certificates, maintaining a comprehensive inventory of all active and expired certificates.
|
||||
|
||||
@@ -1,116 +1,51 @@
|
||||
---
|
||||
title: "Projects"
|
||||
title: "Overview"
|
||||
description: "Learn more and understand the concept of Infisical projects."
|
||||
---
|
||||
|
||||
A project in Infisical belongs to an [organization](./organization) and contains a number of environments, folders, and secrets.
|
||||
Only users and machine identities who belong to a project can access resources inside of it according to predefined permissions.
|
||||
## Projects
|
||||
|
||||
Infisical also allows users to request project access. Refer to the [project access request section](./access-controls/project-access-requests)
|
||||
A project defines a specific scope of work for a given product line in Infisical.
|
||||
|
||||
## Project environments
|
||||
Projects are created within an [organization](/documentation/platform/organization), and an organization can contain multiple projects across different product types.
|
||||
|
||||
For both visual and organizational structure, Infisical allows splitting up secrets into environments (e.g., development, staging, production). In project settings, such environments can be
|
||||
customized depending on the intended use case.
|
||||
## Project Types
|
||||
|
||||
|
||||
Infisical supports project types, each representing a different security product with its own dashboard, workflows, and capabilities.
|
||||
|
||||
## Secrets Overview
|
||||
|
||||
|
||||
The **Secrets Overview** page captures a birds-eye-view of secrets and [folders](./folder) across environments.
|
||||
This is useful for comparing secrets, identifying if anything is missing, and making quick changes.
|
||||
The supported project types are:
|
||||
|
||||
|
||||
- [Secrets Management](/documentation/platform/secrets-mgmt/overview): Securely store, access, and distribute secrets across environments with fine-grained controls, automatic rotation, and audit logging.
|
||||
- [Secrets Scanning](/documentation/platform/secret-scanning/overview): Detect hardcoded secrets in code, CI pipelines, and infrastructure—integrated with GitHub, GitLab, Bitbucket, and more.
|
||||
- [Infisical PKI](/documentation/platform/pki/overview): Issue and manage X.509 certificates using protocols like EST, with support for internal and external CAs.
|
||||
- [Infisical SSH](/documentation/platform/ssh/overview): Provide short-lived SSH access to servers using certificate-based authentication, replacing static keys with policy-driven, time-bound control.
|
||||
- [Infisical KMS](/documentation/platform/kms/overview): Encrypt and decrypt data using centrally managed keys with enforced access policies and full audit visibility.
|
||||
|
||||
## Secrets Dashboard
|
||||
## Roles and Access Control
|
||||
|
||||
The **Secrets Dashboard** page appears when you press to manage the secrets of a specific environment.
|
||||
[Users](/documentation/platform/identities/user-identities) and [machine identities](/documentation/platform/identities/machine-identities) must be added to a project to access its resources. Each identity is assigned a [project-level role](/documentation/platform/access-controls/role-based-access-controls#project-level-access-controls) that defines what they can manage—such as secrets, certificates, or SSH access. These roles apply to both individuals and [user groups](/documentation/platform/groups), enabling scalable access across teams and environments.
|
||||
|
||||
|
||||
Project access is strictly scoped: only members of a project can view or manage its resources. If someone needs access but isn’t part of the project, they can submit an access request.
|
||||
|
||||
### Secrets
|
||||
Each project in Infisical has its own [access control model](/documentation/platform/access-controls/role-based-access-controls#project-level-access-controls), distinct from [organization-level access control](/documentation/platform/access-controls/role-based-access-controls#organization-level-access-controls). While organization roles govern broader administrative access, project-level roles control what users, groups, and machine identities can do within the boundaries of a specific project—such as managing secrets, issuing certificates, or configuring SSH access.
|
||||
|
||||
To add a secret, press **Add Secret** button at the top of the dashboard.
|
||||
Depending on the project type (e.g. Secrets Management, PKI, SSH), project-level access control supports advanced features like [temporary access](/documentation/platform/access-controls/temporary-access), [access requests](/documentation/platform/access-controls/access-requests), and [additional privileges](/documentation/platform/access-controls/additional-privileges).
|
||||
|
||||
|
||||
|
||||
|
||||
For a new project, it can be convenient to populate the dashboard by dropping a `.env` file into the provided pane as shown below:
|
||||
To learn more about how permissions work in detail, refer to the [access control documentation](/documentation/platform/access-controls/overview).
|
||||
|
||||
|
||||
## Audit Logs
|
||||
|
||||
To delete a secret, hover over it and press the **X** button that appears on the right side.
|
||||
Infisical provides [audit logging](/documentation/platform/audit-logs) at the project level to help teams monitor activity and maintain accountability within a specific project. These logs capture all relevant events—such as secret access, certificate issuance, and SSH activity—that occur within the boundaries of that project.
|
||||
|
||||
|
||||
Unlike the organization-level audit view, which aggregates logs across all projects in one centralized interface, the project-level audit view is scoped to a single project. This enables relevant project admins and contributors to review activity relevant to their work without having broader access to audit logs in other projects that they are not part of.
|
||||
|
||||
To delete multiple secrets at once, hover over and select the secrets you'd like to delete
|
||||
and press the **Delete** button that appears at the top.
|
||||
## Project Settings
|
||||
|
||||
|
||||
Each project has its own settings panel, with options that vary depending on the selected product type. These may include
|
||||
setup and configuration for environments, tags, behaviors, encryption strategies, and other options.
|
||||
|
||||
### Search
|
||||
|
||||
To search for specific secrets by their key name, you can use the search bar.
|
||||
|
||||
|
||||
|
||||
To assist you with finding secrets, you can also group them by similar prefixes and filter them by tags (if applicable).
|
||||
|
||||
|
||||
|
||||
### Hide/Un-hide
|
||||
|
||||
To view/hide all secrets at once, toggle the hide or un-hide button.
|
||||
|
||||
|
||||
|
||||
### Download as .env
|
||||
|
||||
To download/export secrets back into a `.env` file, press the download button.
|
||||
|
||||
|
||||
|
||||
### Tags
|
||||
|
||||
To better organize similar secrets, hover over them and label them with a tag.
|
||||
|
||||
|
||||
|
||||
### Comments
|
||||
|
||||
To provide more context about a given secret, especially for your team, hover over it and press the comment button.
|
||||
|
||||
|
||||
|
||||
### Personal overrides
|
||||
|
||||
Infisical employs the concept of **shared** and **personal** secrets to address the need
|
||||
for common and custom secret values, or branching, amongst members of a team during software development.
|
||||
To provide a helpful analogy: A shared value is to a `main` branch as a personal value is to a custom branch.
|
||||
|
||||
Consider:
|
||||
|
||||
- A team with users A, B, user C.
|
||||
- A project with an environment containing a shared secret called D with the value E.
|
||||
|
||||
Suppose user A overrides the value of secret D with the value F.
|
||||
|
||||
Then:
|
||||
|
||||
- If user A fetches the secret D back, they get the value F.
|
||||
- If users B and C fetch the secret D back, they both get the value E.
|
||||
|
||||
<Info>
|
||||
Please keep in mind that secret reminders won't work with personal overrides.
|
||||
</Info>
|
||||
|
||||
|
||||
|
||||
### Drawer
|
||||
|
||||
To view the full details of each secret, you can hover over it and press on the ellipses button.
|
||||
|
||||
|
||||
|
||||
This opens up a side-drawer:
|
||||
|
||||
|
||||
Project settings are fully independent and reflect the capabilities of the associated product.
|
||||
|
||||
17
docs/documentation/platform/secrets-mgmt/overview.mdx
Normal file
17
docs/documentation/platform/secrets-mgmt/overview.mdx
Normal file
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: "Secrets Management"
|
||||
sidebarTitle: "Overview"
|
||||
description: "Learn how to securely store, access, and manage sensitive application secrets."
|
||||
---
|
||||
|
||||
Infisical provides a flexible platform for managing application secrets — such as API keys, database credentials, application configuration, and more — across every stage of the development lifecycle from local development to production.
|
||||
|
||||
It helps teams eliminate hardcoded secrets, enforce access controls, and adopt secure workflows like secret rotation, dynamic secrets, and secrets syncs to external platforms.
|
||||
|
||||
Core capabilities include:
|
||||
|
||||
- Secret Stores: Secure, versioned storage scoped by [project](/documentation/platform/secrets-mgmt/project), [environment](/documentation/platform/secrets-mgmt/project#project-environments), and [path](/documentation/platform/folder).
|
||||
- [Access Control](/documentation/platform/access-controls/overview): Fine-grained, identity-aware permissions for users and machines
|
||||
- Secret Delivery: Access secrets via [CLI](/cli/overview), [SDKs](/sdks/overview) (Go, Node.js, Python, etc.), [HTTP API](/api-reference/overview/introduction), [agents](/integrations/platforms/infisical-agent), [Kubernetes Operator](/integrations/platforms/kubernetes/overview), [External Secrets Operator (ESO)](https://external-secrets.io/latest/provider/infisical), and more.
|
||||
- Lifecycle Automation: Automate [secret rotation](/documentation/platform/secret-rotation/overview), generate [dynamic secrets](/documentation/platform/dynamic-secrets/overview), and enforce [approval-based workflows](/documentation/platform/pr-workflows).
|
||||
- [Secrets Syncs](/integrations/secret-syncs/overview): Push secrets to external services like [GitHub](/integrations/secret-syncs/github), [GitLab](/integrations/secret-syncs/gitlab), [AWS Secrets Manager](/integrations/secret-syncs/aws-secrets-manager), [Vercel](/integrations/secret-syncs/vercel), and more.
|
||||
115
docs/documentation/platform/secrets-mgmt/project.mdx
Normal file
115
docs/documentation/platform/secrets-mgmt/project.mdx
Normal file
@@ -0,0 +1,115 @@
|
||||
---
|
||||
title: "Projects"
|
||||
description: "Learn more and understand the concept of Infisical projects."
|
||||
---
|
||||
|
||||
A secrets management project in Infisical is a dedicated workspace for managing application secrets such as API keys, database credentials, configuration, etc. used by your applications.
|
||||
|
||||
Secrets are organized into a clear hierarchy of environments, folders, and individual secrets, making it easy to manage values across different stages of your development lifecycle (e.g., development, staging, production).
|
||||
|
||||
## Project environments
|
||||
|
||||
For both visual and organizational structure, Infisical allows splitting up secrets into environments (e.g., development, staging, production). In project settings, such environments can be
|
||||
customized depending on the intended use case.
|
||||
|
||||
|
||||
|
||||
## Secrets Overview
|
||||
|
||||
The **Secrets Overview** page captures a birds-eye-view of secrets and [folders](./folder) across environments.
|
||||
This is useful for comparing secrets, identifying if anything is missing, and making quick changes.
|
||||
|
||||
|
||||
|
||||
## Secrets Dashboard
|
||||
|
||||
The **Secrets Dashboard** page appears when you press to manage the secrets of a specific environment.
|
||||
|
||||
|
||||
|
||||
### Secrets
|
||||
|
||||
To add a secret, press **Add Secret** button at the top of the dashboard.
|
||||
|
||||
|
||||
|
||||
For a new project, it can be convenient to populate the dashboard by dropping a `.env` file into the provided pane as shown below:
|
||||
|
||||
|
||||
|
||||
To delete a secret, hover over it and press the **X** button that appears on the right side.
|
||||
|
||||
|
||||
|
||||
To delete multiple secrets at once, hover over and select the secrets you'd like to delete
|
||||
and press the **Delete** button that appears at the top.
|
||||
|
||||
|
||||
|
||||
### Search
|
||||
|
||||
To search for specific secrets by their key name, you can use the search bar.
|
||||
|
||||
|
||||
|
||||
To assist you with finding secrets, you can also group them by similar prefixes and filter them by tags (if applicable).
|
||||
|
||||
|
||||
|
||||
### Hide/Un-hide
|
||||
|
||||
To view/hide all secrets at once, toggle the hide or un-hide button.
|
||||
|
||||
|
||||
|
||||
### Download as .env
|
||||
|
||||
To download/export secrets back into a `.env` file, press the download button.
|
||||
|
||||
|
||||
|
||||
### Tags
|
||||
|
||||
To better organize similar secrets, hover over them and label them with a tag.
|
||||
|
||||
|
||||
|
||||
### Comments
|
||||
|
||||
To provide more context about a given secret, especially for your team, hover over it and press the comment button.
|
||||
|
||||
|
||||
|
||||
### Personal overrides
|
||||
|
||||
Infisical employs the concept of **shared** and **personal** secrets to address the need
|
||||
for common and custom secret values, or branching, amongst members of a team during software development.
|
||||
To provide a helpful analogy: A shared value is to a `main` branch as a personal value is to a custom branch.
|
||||
|
||||
Consider:
|
||||
|
||||
- A team with users A, B, user C.
|
||||
- A project with an environment containing a shared secret called D with the value E.
|
||||
|
||||
Suppose user A overrides the value of secret D with the value F.
|
||||
|
||||
Then:
|
||||
|
||||
- If user A fetches the secret D back, they get the value F.
|
||||
- If users B and C fetch the secret D back, they both get the value E.
|
||||
|
||||
<Info>
|
||||
Please keep in mind that secret reminders won't work with personal overrides.
|
||||
</Info>
|
||||
|
||||
|
||||
|
||||
### Drawer
|
||||
|
||||
To view the full details of each secret, you can hover over it and press on the ellipses button.
|
||||
|
||||
|
||||
|
||||
This opens up a side-drawer:
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "Infisical SSH"
|
||||
title: "Host Groups"
|
||||
sidebarTitle: "Host Groups"
|
||||
description: "Learn how to organize SSH hosts into groups and manage access policies at scale."
|
||||
---
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "Infisical SSH"
|
||||
title: "Overview"
|
||||
sidebarTitle: "Overview"
|
||||
description: "Learn how to securely provision user SSH access to your infrastructure using SSH certificates."
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user