awatertrevi/infisical
1
0
Fork 0
mirror of https://github.com/awatertrevi/infisical.git synced 2026-09-22 13:39:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'misc/privilege-management-v2-transition' of https://github.com/Infisical/infisical into misc/privilege-management-v2-transition

Browse Source
This commit is contained in:
Sheen
2025-03-19 20:00:18 +00:00
parent 2d5b7afda7 4f08801ae8
commit fa7843983f
266 changed files with 6756 additions and 914 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/api-reference/endpoints/app-connections/humanitec/available.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Available"
openapi: "GET /api/v1/app-connections/humanitec/available"
---

4
docs/api-reference/endpoints/app-connections/humanitec/create.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Create"
openapi: "POST /api/v1/app-connections/humanitec"
---

4
docs/api-reference/endpoints/app-connections/humanitec/delete.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Delete"
openapi: "DELETE /api/v1/app-connections/humanitec/{connectionId}"
---

4
docs/api-reference/endpoints/app-connections/humanitec/get-by-id.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Get by ID"
openapi: "GET /api/v1/app-connections/humanitec/{connectionId}"
---

4
docs/api-reference/endpoints/app-connections/humanitec/get-by-name.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Get by Name"
openapi: "GET /api/v1/app-connections/humanitec/connection-name/{connectionName}"
---

4
docs/api-reference/endpoints/app-connections/humanitec/list.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "List"
openapi: "GET /api/v1/app-connections/humanitec"
---

4
docs/api-reference/endpoints/app-connections/humanitec/update.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Update"
openapi: "PATCH /api/v1/app-connections/humanitec/{connectionId}"
---

4
docs/api-reference/endpoints/secret-syncs/humanitec/create.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Create"
openapi: "POST /api/v1/secret-syncs/humanitec"
---

4
docs/api-reference/endpoints/secret-syncs/humanitec/delete.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Delete"
openapi: "DELETE /api/v1/secret-syncs/humanitec/{syncId}"
---

4
docs/api-reference/endpoints/secret-syncs/humanitec/get-by-id.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Get by ID"
openapi: "GET /api/v1/secret-syncs/humanitec/{syncId}"
---

4
docs/api-reference/endpoints/secret-syncs/humanitec/get-by-name.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Get by Name"
openapi: "GET /api/v1/secret-syncs/humanitec/sync-name/{syncName}"
---

4
docs/api-reference/endpoints/secret-syncs/humanitec/list.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "List"
openapi: "GET /api/v1/secret-syncs/humanitec"
---

4
docs/api-reference/endpoints/secret-syncs/humanitec/remove-secrets.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Remove Secrets"
openapi: "POST /api/v1/secret-syncs/humanitec/{syncId}/remove-secrets"
---

4
docs/api-reference/endpoints/secret-syncs/humanitec/sync-secrets.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Sync Secrets"
openapi: "POST /api/v1/secret-syncs/humanitec/{syncId}/sync-secrets"
---

4
docs/api-reference/endpoints/secret-syncs/humanitec/update.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Update"
openapi: "PATCH /api/v1/secret-syncs/humanitec/{syncId}"
---

15
docs/cli/commands/secrets.mdx
View File

@@ -219,6 +219,21 @@ $ infisical secrets set STRIPE_API_KEY=sjdgwkeudyjwe DOMAIN=example.com HASH=jeb
```
</Accordion>
<Accordion title="--file">
Used to set secrets from a file, supporting both `.env` and `YAML` formats. The file path can be either absolute or relative to the current working directory.
The file should contain secrets in the following formats:
- `key=value` for `.env` files
- `key: value` for YAML files
Comments can be written using `# comment` or `// comment`. Empty lines will be ignored during processing.
```bash
# Example
infisical secrets set --file="./.env"
```
</Accordion>
</Accordion>
<Accordion title="infisical secrets delete">

2
docs/documentation/guides/local-development.mdx
View File

@@ -6,7 +6,7 @@ description: "Learn how to manage secrets in local development environments."
## Problem at hand
There is a number of issues that arise with secret management in local development environment:
There are a number of issues that arise with secret management in local development environment:
1. **Getting secrets onto local machines**. When new developers join or a new project is created, the process of getting the development set of secrets onto local machines is often unclear. As a result, developers end up spending a lot of time onboarding and risk potentially following insecure practices when sharing secrets from one developer to another.
2. **Syncing secrets with teammates**. One of the problems with .env files is that they become unsynced when one of the developers updates a secret or configuration. Even if the rest of the team is notified, developers don't make all the right changes immediately, and later on end up spending a lot of time debugging an issue due to missing environment variables. This leads to a lot of inefficiencies and lost time.
3. **Accidentally leaking secrets**. When developing locally, it's common for developers to accidentally leak a hardcoded secret as part of a commit. As soon as the secret is part of the git history, it becomes hard to get it removed and create a security vulnerability.

BIN
docs/documentation/platform/access-controls/abac/images/add-metadata-on-machine-identity-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.0 MiB

BIN
docs/documentation/platform/access-controls/abac/images/add-metadata-on-machine-identity-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.1 MiB

BIN
docs/documentation/platform/access-controls/abac/images/add-metadata-on-machine-identity-3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 641 KiB

68
docs/documentation/platform/access-controls/abac/managing-machine-identity-attributes.mdx Normal file
View File

@@ -0,0 +1,68 @@
---
title: "Machine identities"
description: "Learn how to set metadata and leverage authentication attributes for machine identities."
---
Machine identities can have metadata set manually, just like users. In addition, during the machine authentication process (e.g., via OIDC), extra attributes called claims—are provided, which can be used in your ABAC policies.
#### Setting Metadata on Machine Identities
<Tabs>
<Tab title="Manually Configure Metadata">
<Steps>
<Step title="Navigate to the Access Control page on the organization sidebar and select a machine identity.">
<img src="/documentation/platform/access-controls/abac/images/add-metadata-on-machine-identity-1.png" />
</Step>
<Step title="On the machine identity page, click the pencil icon to edit the selected identity.">
<img src="/documentation/platform/access-controls/abac/images/add-metadata-on-machine-identity-2.png" />
</Step>
<Step title="Add metadata via key-value pairs and update the machine identity.">
<img src="/documentation/platform/access-controls/abac/images/add-metadata-on-machine-identity-3.png" />
</Step>
</Steps>
</Tab>
</Tabs>
#### Accessing Attributes From Machine Identity Login
When machine identities authenticate, they may receive additional payloads/attributes from the service provider.
For methods like OIDC, these come as claims in the token and can be made available in your policies.
<Tabs>
<Tab title="OIDC Login Attributes">
1. Navigate to the Identity Authentication settings and select the OIDC Auth Method.
2. In the **Advanced section**, locate the Claim Mapping configuration.
3. Map the OIDC claims to permission attributes by specifying:
- **Attribute Name:** The identifier to be used in your policies (e.g., department).
- **Claim Path:** The dot notation path to the claim in the OIDC token (e.g., user.department).
For example, if your OIDC provider returns:
```json
{
"sub": "machine456",
"name": "Service A",
"user": {
"department": "engineering",
"role": "service"
}
}
```
You might map:
- **department:** to `user.department`
- **role:** to `user.role`
Once configured, these attributes become available in your policies using the following format:
```
{{ identity.auth.oidc.claims.<permission claim name> }}
```
<img src="/images/platform/access-controls/abac-policy-oidc-format.png" />
</Tab>
<Tab title="Other Authentication Method Attributes">
At the moment we only support OIDC claims. Payloads on other authentication methods are not yet accessible.
</Tab>
</Tabs>

39
docs/documentation/platform/access-controls/abac/managing-user-metadata.mdx Normal file
View File

@@ -0,0 +1,39 @@
---
title: "Users identities"
description: "How to set and use metadata attributes on user identities for ABAC."
---
User identities can have metadata attributes assigned directly. These attributes (such as location or department) are used to define dynamic access policies.
#### Setting Metadata on Users
<Tabs>
<Tab title="Manually Configure Metadata">
<Steps>
<Step title="Navigate to the Access Control page on the organization sidebar and select a user.">
<img src="/images/platform/access-controls/add-metadata-step1.png" />
</Step>
<Step title="On the User Page, click the pencil icon to edit the selected user.">
<img src="/images/platform/access-controls/add-metadata-step2.png" />
</Step>
<Step title="Add metadata via key-value pairs and update the user identity.">
<img src="/images/platform/access-controls/add-metadata-step3.png" />
</Step>
</Steps>
</Tab>
<Tab title="Automatically Populate Metadata">
For organizations using SAML for **user logins**, Infisical automatically maps metadata attributes from SAML assertions to user identities on every login. This enables dynamic policies based on the user's SAML attributes.
</Tab>
</Tabs>
#### Applying ABAC Policies with User Metadata
Attribute-based access controls are currently only available for polices defined on Secrets Manager projects.
You can set ABAC permissions to dynamically set access to environments, folders, secrets, and secret tags.
<img src="/images/platform/access-controls/example-abac-1.png" />
In your policies, metadata values are accessed as follows:
- **User ID:** `{{ identity.id }}` (always available)
- **Username:** `{{ identity.username }}` (always available)
- **Metadata Attributes:** `{{ identity.metadata.<metadata-key-name> }}` (available if set)

15
docs/documentation/platform/access-controls/abac/overview.mdx Normal file
View File

@@ -0,0 +1,15 @@
---
title: "Overview"
description: "Learn the basics of ABAC for both users and machine identities."
---
Infisical's Attribute-based Access Controls (ABAC) enable dynamic, attribute-driven permissions for both users and machine identities. ABAC enforces fine-grained, context-aware access controls using metadata attributes—stored as key-value pairs—either attached to identities or provided during authentication.
<CardGroup cols={2}>
<Card title="Users" icon="square-1" href="./managing-user-metadata">
Manage user metadata manually or automatically via SAML logins.
</Card>
<Card title="Machine Identities" icon="square-2" href="./managing-machine-identity-attributes">
Set metadata manually like users and access additional attributes provided during machine authentication (for example, OIDC claims).
</Card>
</CardGroup>

65
docs/documentation/platform/access-controls/attribute-based-access-controls.mdx
View File

@@ -1,65 +0,0 @@
---
title: "Attribute-based Access Controls"
description: "Learn how to use ABAC to manage permissions based on identity attributes."
---
Infisical's Attribute-based Access Controls (ABAC) allow for dynamic, attribute-driven permissions for both user and machine identities.
ABAC policies use metadata attributes—stored as key-value pairs on identities—to enforce fine-grained permissions that are context aware.
In ABAC, access controls are defined using metadata attributes, such as location or department, which can be set directly on user or machine identities.
During policy execution, these attributes are evaluated, and determine whether said actor can access the requested resource or perform the requested operation.
## Project-level Permissions
Attribute-based access controls are currently available for polices defined on projects. You can set ABAC permissions to control access to environments, folders, secrets, and secret tags.
### Setting Metadata on Identities
<Tabs>
<Tab title="Manually Configure Metadata">
<Steps>
<Step title="Navigate to the Access Control page on the organization sidebar and select an identity (user or machine).">
<img src="/images/platform/access-controls/add-metadata-step1.png" />
</Step>
<Step title="On the Identity Page, click the pencil icon to edit the selected identity.">
<img src="/images/platform/access-controls/add-metadata-step2.png" />
</Step>
<Step title="Add metadata via key-value pairs and update the identity.">
<img src="/images/platform/access-controls/add-metadata-step3.png" />
</Step>
</Steps>
</Tab>
<Tab title="Automatically Populate Metadata">
For organizations using SAML for login, Infisical automatically maps metadata attributes from SAML assertions to user identities.
This makes it easy to create policies that dynamically adapt based on the SAML user’s attributes.
</Tab>
</Tabs>
## Defining ABAC Policies
<img src="/images/platform/access-controls/example-abac-1.png" />
ABAC policies make use of identity metadata to define dynamic permissions. Each attribute must start and end with double curly-brackets `{{ <attribute-name> }}`.
The following attributes are available within project permissions:
- **User ID**: `{{ identity.id }}`
- **Username**: `{{ identity.username }}`
- **Metadata Attributes**: `{{ identity.metadata.<metadata-key-name> }}`
During policy execution, these placeholders are replaced by their actual values prior to evaluation.
### Example Use Case
#### Location-based Access Control
Suppose you want to restrict access to secrets within a specific folder based on a user's geographic region.
You could assign a `location` attribute to each user (e.g., `identity.metadata.location`).
You could then structure your folders to align with this attribute and define permissions accordingly.
For example, a policy might restrict access to folders matching the user's location attribute in the following pattern:
```
/appA/{{ identity.metadata.location }}
```
Using this structure, users can only access folders that correspond to their configured `location` attribute.
Consequently, if a users attribute changes due to relocation, no policies need to be changed to gain access to the folders associated with their new location.

2
docs/documentation/platform/access-controls/overview.mdx
View File

@@ -18,7 +18,7 @@ To make sure that users and machine identities are only accessing the resources
<Card
title="Attribute-based Access Control"
href="./attribute-based-access-controls"
href="/documentation/platform/access-controls/abac"
icon="address-book"
color="#000000"
>

BIN
docs/images/app-connections/humanitec/add-humanitec-connection.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 229 KiB

BIN
docs/images/app-connections/humanitec/humanitec-add-api-token.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 324 KiB

BIN
docs/images/app-connections/humanitec/humanitec-add-user-options.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 302 KiB

BIN
docs/images/app-connections/humanitec/humanitec-add-user-role.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 317 KiB

BIN
docs/images/app-connections/humanitec/humanitec-add-user.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 303 KiB

BIN
docs/images/app-connections/humanitec/humanitec-app-connection-created.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 337 KiB

BIN
docs/images/app-connections/humanitec/humanitec-app-connection-modal.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 230 KiB

BIN
docs/images/app-connections/humanitec/humanitec-app-connection-option.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 234 KiB

BIN
docs/images/app-connections/humanitec/humanitec-applications-tab.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 318 KiB

BIN
docs/images/app-connections/humanitec/humanitec-connection.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 340 KiB

BIN
docs/images/app-connections/humanitec/humanitec-copy-api-token.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 325 KiB

BIN
docs/images/app-connections/humanitec/humanitec-create-api-token.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 330 KiB

BIN
docs/images/app-connections/humanitec/humanitec-create-new-user.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 286 KiB

BIN
docs/images/app-connections/humanitec/humanitec-service-account-filled.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 333 KiB

BIN
docs/images/app-connections/humanitec/humanitec-service-users.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 300 KiB

BIN
docs/images/app-connections/humanitec/humanitec-user-added.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 316 KiB

BIN
docs/images/app-connections/humanitec/select-humanitec-connection.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 232 KiB

BIN
docs/images/platform/access-controls/abac-policies-by-auth.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 478 KiB

BIN
docs/images/platform/access-controls/abac-policy-oidc-format.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 544 KiB

BIN
docs/images/secret-syncs/humanitec/humanitec-created.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 374 KiB

BIN
docs/images/secret-syncs/humanitec/humanitec-destination.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 247 KiB

BIN
docs/images/secret-syncs/humanitec/humanitec-details.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 246 KiB

BIN
docs/images/secret-syncs/humanitec/humanitec-options.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 267 KiB

BIN
docs/images/secret-syncs/humanitec/humanitec-review.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 253 KiB

BIN
docs/images/secret-syncs/humanitec/humanitec-source.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 243 KiB

BIN
docs/images/secret-syncs/humanitec/select-humanitec-option.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 258 KiB

71
docs/integrations/app-connections/humanitec.mdx Normal file
View File

@@ -0,0 +1,71 @@
---
title: "Humanitec Connection"
description: "Learn how to configure a Humanitec Connection for Infisical."
---
Infisical supports connecting to Humanitec using a service user.
## Setup Humanitec Connection in Infisical
<Steps>
<Step title="Move to Service Users on Humanitec">
Navigate to the Humanitec **Service Users** tab.
![Humanitec Service Users Tab](/images/app-connections/humanitec/humanitec-service-users.png)
</Step>
<Step title="Create a Service User">
Create a new service user. Take into account that the role set here will affect the permissions of the API Token so be sure to set it so the Service User has access permissions to the App you want to integrate to Infisical.
![Humanitec Create New Service User](/images/app-connections/humanitec/humanitec-create-new-user.png)
</Step>
<Step title="Add API Token for the Service User">
Add a new API token for the service user.
![Humanitec Add API Token](/images/app-connections/humanitec/humanitec-add-api-token.png)
</Step>
<Step title="Create the API Token for the Service User">
Create the API token for the service user.
This token's permission will be limited to the **Service User** role.
<Note>
If you configure an expiry date for your API token you will need to manually rotate to a new token prior to expiration to avoid integration downtime.
</Note>
![Humanitec Create API Token](/images/app-connections/humanitec/humanitec-create-api-token.png)
</Step>
<Step title="Copy the API Token">
A modal with the API token will be displayed. Save the token in a secure location for later use in the following steps.
![Humanitec Copy API Token](/images/app-connections/humanitec/humanitec-copy-api-token.png)
</Step>
<Step title="Service User has been successfully created">
After following the previous steps the Service User has been successfully created, and now should be visible on the Service Users tab.
![Humanitec Service User Created](/images/app-connections/humanitec/humanitec-service-account-filled.png)
</Step>
<Step title="Add Service User to Application">
Move to the **Applications** tab and add the Service User to the Application you want to sync with Infisical.
Clicking on the App Title will open the App details page.
![Humanitec Applications Tab](/images/app-connections/humanitec/humanitec-applications-tab.png)
</Step>
<Step title="Add new member to this Application">
Move to the **People** tab and add a new member to this Application. The recently created User Service should be visible on the dropdown shown.
Make sure to assign at least Developer role as Write permissions are required.
![Humanitec Add User to Application](/images/app-connections/humanitec/humanitec-add-user.png)
![Humanitec Add User Options](/images/app-connections/humanitec/humanitec-add-user-options.png)
![Humanitec Add User Role](/images/app-connections/humanitec/humanitec-add-user-role.png)
</Step>
<Step title="Connection Created">
Your **Humanitec Connection** is now available for use.
![Humanitec Connection Created](/images/app-connections/humanitec/humanitec-user-added.png)
</Step>
<Step title="Navigate to App Connections">
Navigate to the **App Connections** tab on the **Organization Settings** page.
![App Connections Tab](/images/app-connections/general/add-connection.png)
</Step>
<Step title="Add Connection">
Select the **Humanitec Connection** option from the connection options modal.
![Select Humanitec Connection](/images/app-connections/humanitec/humanitec-app-connection-option.png)
</Step>
<Step title="Fill the Humanitec Connection Modal">
Fill the Humanitec Connection modal, here you will need to provide the User Service API Token generated in the previous step.
![Humanitec Connection Modal](/images/app-connections/humanitec/humanitec-app-connection-modal.png)
</Step>
<Step title="Connection Created">
Your **Humanitec Connection** is now available for use.
![Humanitec Connection Created](/images/app-connections/humanitec/humanitec-app-connection-created.png)
</Step>
</Steps>

4
docs/integrations/platforms/kubernetes/infisical-dynamic-secret-crd.mdx
View File

@@ -137,10 +137,8 @@ When `hostAPI` is not defined the operator fetches secrets from Infisical Cloud.
<Note>
The lease duration at most be 1 day (24 hours). And the TTL must be less than the max TTL defined on the dynamic secret.
</Note>
</Accordion>
</Accordion>
<Accordion title="managedSecretReference">
The `managedSecretReference` field is used to define the Kubernetes secret where the dynamic secret lease should be stored. The required fields are `secretName` and `secretNamespace`.

387
docs/integrations/platforms/kubernetes/infisical-secret-crd.mdx
View File

@@ -93,7 +93,7 @@ When `hostAPI` is not defined the operator fetches secrets from Infisical Cloud.
CA certificate to use for connecting to the Infisical instance with SSL/TLS.
</Accordion>
### Authentication methods
### Authentication Methods
To retrieve the requested secrets, the operator must first authenticate with Infisical.
The list of available authentication methods are shown below.
@@ -535,7 +535,7 @@ spec:
</Accordion>
### Operator managed secrets
### Operator Managed Secrets
The managed secret properties specify where to store the secrets retrieved from your Infisical project.
This includes defining the name and namespace of the Kubernetes secret that will hold these secrets.
@@ -584,7 +584,7 @@ This is useful for tools such as ArgoCD, where every resource requires an owner
</Accordion>
### Manged secret templating
#### Managed Secret Templating
Fetching secrets from Infisical as is via the operator may not be enough. This is where templating functionality may be helpful.
Using Go templates, you can format, combine, and create new key-value pairs from secrets fetched from Infisical before storing them as Kubernetes Secrets.
@@ -681,6 +681,135 @@ template:
</Accordion>
### Operator Managed ConfigMaps
The managed config map properties specify where to store the secrets retrieved from your Infisical project. Config maps can be used to store **non-sensitive** data, such as application configuration variables.
The properties includes defining the name and namespace of the Kubernetes config map that will hold the data retrieved from your Infisical project.
The Infisical operator will automatically create the Kubernetes config map in the specified name/namespace and ensure it stays up-to-date. If a config map already exists in the specified namespace, the operator will update the existing config map with the new data.
<Warning>
The usage of config maps is only intended for storing non-sensitive data. If you are looking to store sensitive data, please use the [managed secret](#operator-managed-secrets) property instead.
</Warning>
<Accordion title="managedKubeConfigMapReferences">
</Accordion>
<Accordion title="managedKubeConfigMapReferences[].configMapName">
The name of the managed Kubernetes config map that your Infisical data will be stored in.
</Accordion>
<Accordion title="managedKubeConfigMapReferences[].configMapNamespace">
The namespace of the managed Kubernetes config map that your Infisical data will be stored in.
</Accordion>
<Accordion title="managedKubeConfigMapReferences[].creationPolicy">
Creation polices allow you to control whether or not owner references should be added to the managed Kubernetes config map that is generated by the Infisical operator.
This is useful for tools such as ArgoCD, where every resource requires an owner reference; otherwise, it will be pruned automatically.
#### Available options
- `Orphan` (default)
- `Owner`
<Tip>
When creation policy is set to `Owner`, the `InfisicalSecret` CRD must be in
the same namespace as where the managed kubernetes config map.
</Tip>
</Accordion>
#### Managed ConfigMap Templating
Fetching secrets from Infisical as is via the operator may not be enough. This is where templating functionality may be helpful.
Using Go templates, you can format, combine, and create new key-value pairs from secrets fetched from Infisical before storing them as Kubernetes Config Maps.
<Accordion title="managedKubeConfigMapReferences[].template">
</Accordion>
<Accordion title="managedKubeConfigMapReferences[].template.includeAllSecrets">
This property controls what secrets are included in your managed config map when using templates.
When set to `true`, all secrets fetched from your Infisical project will be added into your managed Kubernetes config map resource.
**Use this option when you would like to sync all secrets from Infisical to Kubernetes but want to template a subset of them.**
When set to `false`, only secrets defined in the `managedKubeConfigMapReferences[].template.data` field of the template will be included in the managed config map.
Use this option when you would like to sync **only** a subset of secrets from Infisical to Kubernetes.
</Accordion>
<Accordion title="managedKubeConfigMapReferences[].template.data">
Define secret keys and their corresponding templates.
Each data value uses a Golang template with access to all secrets retrieved from the specified scope.
Secrets are structured as follows:
```golang
type TemplateSecret struct {
Value string `json:"value"`
SecretPath string `json:"secretPath"`
}
```
#### Example template configuration:
```yaml
managedKubeConfigMapReferences:
- configMapName: managed-configmap
configMapNamespace: default
template:
includeAllSecrets: true
data:
# Create new key that doesn't exist in your Infisical project using values of other secrets
SITE_URL: "{{ .SITE_URL.Value }}"
# Override an existing key in Infisical project with a new value using values of other secrets
API_URL: "https://api.{{.SITE_URL.Value}}.{{.REGION.Value}}.com"
```
For this example, let's assume the following secrets exist in your Infisical project:
```
SITE_URL = "https://example.com"
REGION = "us-east-1"
API_URL = "old-url" # This will be overridden
```
The resulting managed Kubernetes config map will then contain:
```
# Original config map data (from includeAllSecrets: true)
SITE_URL = "https://example.com"
REGION = "us-east-1"
# New and overridden config map data
SITE_URL = "https://example.com"
API_URL = "https://api.example.com.us-east-1.com" # Existing secret overridden by template
```
To help transform your config map data further, the operator provides a set of built-in functions that you can use in your templates.
### Available templating functions
<Accordion title="decodeBase64ToBytes">
**Function name**: decodeBase64ToBytes
**Description**:
Given a base64 encoded string, this function will decodes the base64-encoded string.
This function is useful when your Infisical secrets are already stored as base64 encoded value in Infisical.
**Returns**: The decoded base64 string as bytes.
**Example**:
The example below assumes that the `BINARY_KEY_BASE64` secret is stored as a base64 encoded value in Infisical.
The resulting managed config map will contain the decoded value of `BINARY_KEY_BASE64`.
```yaml
managedKubeConfigMapReferences:
- configMapName: managed-configmap
configMapNamespace: default
template:
includeAllSecrets: true
data:
BINARY_KEY: "{{ decodeBase64ToBytes .BINARY_KEY_BASE64.Value }}"
```
</Accordion>
</Accordion>
## Applying CRD
Once you have configured the InfisicalSecret CRD with the required fields, you can apply it to your cluster.
@@ -692,17 +821,32 @@ kubectl apply -f example-infisical-secret-crd.yaml
To verify that the operator has successfully created the managed secret, you can check the secrets in the namespace that was specified.
```bash
# Verify managed secret is created
kubectl get secrets -n <namespace of managed secret>
```
<Tabs>
<Tab title="Managed Secret">
```bash
# Verify managed secret is created
kubectl get secrets -n <namespace of managed secret>
```
<Info>
The Infisical secrets will be synced and stored into the managed secret every
1 minute unless configured otherwise.
</Info>
</Tab>
<Tab title="Managed ConfigMap">
```bash
# Verify managed config map is created
kubectl get configmaps -n <namespace of managed config map>
```
<Info>
The Infisical config map data will be synced and stored into the managed config map every
1 minute unless configured otherwise.
</Info>
</Tab>
</Tabs>
<Info>
The Infisical secrets will be synced and stored into the managed secret every
1 minutes.
</Info>
## Using managed secret in your deployment
## Using Managed Secret In Your Deployment
To make use of the managed secret created by the operator into your deployment can be achieved through several methods.
Here, we will highlight three of the most common ways to utilize it. Learn more about Kubernetes secrets [here](https://kubernetes.io/docs/concepts/configuration/secret/)
@@ -755,7 +899,7 @@ spec:
valueFrom:
secretKeyRef:
name: managed-secret # managed secret name
key: SOME_SECRET_KEY # The name of the key which exists in the managed secret
key: SOME_SECRET_KEY # The name of the key which exists in the managed secret
```
Example usage in a deployment
@@ -764,28 +908,30 @@ Example usage in a deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers: - name: nginx
image: nginx:1.14.2
env: - name: STRIPE_API_SECRET
valueFrom:
secretKeyRef:
name: managed-secret # <- name of managed secret
key: STRIPE_API_SECRET
ports: - containerPort: 80
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
env:
- name: STRIPE_API_SECRET
valueFrom:
secretKeyRef:
name: managed-secret # <- name of managed secret
key: STRIPE_API_SECRET
ports:
- containerPort: 80
```
</Accordion>
@@ -861,12 +1007,12 @@ stringData:
-----END CERTIFICATE-----
```
### Auto redeployment
### Automatic Redeployment
Deployments using managed secrets don't reload automatically on updates, so they may use outdated secrets unless manually redeployed.
To address this, we added functionality to automatically redeploy your deployment when its managed secret updates.
#### Enabling auto redeploy
#### Enabling Automatic Redeployment
To enable auto redeployment you simply have to add the following annotation to the deployment, statefulset, or daemonset that consumes a managed secret.
@@ -910,7 +1056,173 @@ spec:
Then, for each deployment that has this annotation present, a rolling update will be triggered.
</Info>
## Propagating labels & annotations
## Using Managed ConfigMap In Your Deployment
To make use of the managed ConfigMap created by the operator into your deployment can be achieved through several methods.
Here, we will highlight three of the most common ways to utilize it. Learn more about Kubernetes ConfigMaps [here](https://kubernetes.io/docs/concepts/configuration/configmap/)
<Tip>
Automatic redeployment of deployments using managed ConfigMaps is not yet supported.
</Tip>
<Accordion title="envFrom">
This will take all the secrets from your managed ConfigMap and expose them to your container
````yaml
envFrom:
- configMapRef:
name: managed-configmap # managed configmap name
```
Example usage in a deployment
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
envFrom:
- configMapRef:
name: managed-configmap # <- name of managed configmap
ports:
- containerPort: 80
````
</Accordion>
<Accordion title="env">
This will allow you to select individual secrets by key name from your managed ConfigMap and expose them to your container
```yaml
env:
- name: CONFIG_NAME # The environment variable's name which is made available in the container
valueFrom:
configMapKeyRef:
name: managed-configmap # managed configmap name
key: SOME_CONFIG_KEY # The name of the key which exists in the managed configmap
```
Example usage in a deployment
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
env:
- name: STRIPE_API_SECRET
valueFrom:
configMapKeyRef:
name: managed-configmap # <- name of managed configmap
key: STRIPE_API_SECRET
ports:
- containerPort: 80
```
</Accordion>
<Accordion title="volumes">
This will allow you to create a volume on your container which comprises of files holding the secrets in your managed kubernetes secret
```yaml
volumes:
- name: configmaps-volume-name # The name of the volume under which configmaps will be stored
configMap:
name: managed-configmap # managed configmap name
````
You can then mount this volume to the container's filesystem so that your deployment can access the files containing the managed secrets
```yaml
volumeMounts:
- name: configmaps-volume-name
mountPath: /etc/config
readOnly: true
```
Example usage in a deployment
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
volumeMounts:
- name: configmaps-volume-name
mountPath: /etc/config
readOnly: true
ports:
- containerPort: 80
volumes:
- name: configmaps-volume-name
configMap:
name: managed-configmap # <- managed configmap
```
</Accordion>
The definition file of the Kubernetes secret for the CA certificate can be structured like the following:
```yaml
apiVersion: v1
kind: Secret
metadata:
name: custom-ca-certificate
type: Opaque
stringData:
ca.crt: |
-----BEGIN CERTIFICATE-----
MIIEZzCCA0+gAwIBAgIUDk9+HZcMHppiNy0TvoBg8/aMEqIwDQYJKoZIhvcNAQEL
...
BQAwDTELMAkGA1UEChMCUEgwHhcNMjQxMDI1MTU0MjAzWhcNMjUxMDI1MjE0MjAz
-----END CERTIFICATE-----
```
## Propagating Labels & Annotations
The operator will transfer all labels & annotations present on the `InfisicalSecret` CRD to the managed Kubernetes secret to be created.
Thus, if a specific label is required on the resulting secret, it can be applied as demonstrated in the following example:
@@ -949,5 +1261,4 @@ metadata:
namespace: default
type: Opaque
```
</Accordion>

5
docs/integrations/secret-syncs/aws-parameter-store.mdx
View File

@@ -43,8 +43,11 @@ description: "Learn how to configure an AWS Parameter Store Sync for Infisical."
- **KMS Key**: The AWS KMS key ID or alias to encrypt parameters with.
- **Tags**: Optional resource tags to add to parameters synced by Infisical.
- **Sync Secret Metadata as Resource Tags**: If enabled, metadata attached to secrets will be added as resource tags to parameters synced by Infisical.
<Note>Manually configured tags from the **Tags** field will take precedence over secret metadata when tag keys conflict.</Note>
<Note>
Manually configured tags from the **Tags** field will take precedence over secret metadata when tag keys conflict.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
6. Configure the **Details** of your Parameter Store Sync, then click **Next**.
![Configure Details](/images/secret-syncs/aws-parameter-store/aws-parameter-store-details.png)

4
docs/integrations/secret-syncs/aws-secrets-manager.mdx
View File

@@ -46,7 +46,11 @@ description: "Learn how to configure an AWS Secrets Manager Sync for Infisical."
- **KMS Key**: The AWS KMS key ID or alias to encrypt secrets with.
- **Tags**: Optional tags to add to secrets synced by Infisical.
- **Sync Secret Metadata as Tags**: If enabled, metadata attached to secrets will be added as tags to secrets synced by Infisical.
<Note>
Manually configured tags from the **Tags** field will take precedence over secret metadata when tag keys conflict.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
6. Configure the **Details** of your Secrets Manager Sync, then click **Next**.
![Configure Details](/images/secret-syncs/aws-secrets-manager/aws-secrets-manager-details.png)

3
docs/integrations/secret-syncs/azure-app-configuration.mdx
View File

@@ -6,7 +6,7 @@ description: "Learn how to configure an Azure App Configuration Sync for Infisic
**Prerequisites:**
- Set up and add secrets to [Infisical Cloud](https://app.infisical.com)
- Create a [Azure Connection](/integrations/app-connections/azure), configured for Azure App Configuration.
- Create an [Azure App Configuration Connection](/integrations/app-connections/azure-app-configuration)
<Note>
The Azure App Configuration Secret Sync requires the following permissions to be set on the user / service principal
@@ -50,6 +50,7 @@ description: "Learn how to configure an Azure App Configuration Sync for Infisic
- **Import Secrets (Prioritize Azure App Configuration)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Secrets Manager over Infisical when keys conflict.
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
6. Configure the **Details** of your Azure App Configuration Sync, then click **Next**.
![Configure Details](/images/secret-syncs/azure-app-configuration/app-config-details.png)

3
docs/integrations/secret-syncs/azure-key-vault.mdx
View File

@@ -6,7 +6,7 @@ description: "Learn how to configure a Azure Key Vault Sync for Infisical."
**Prerequisites:**
- Set up and add secrets to [Infisical Cloud](https://app.infisical.com)
- Create a [Azure Connection](/integrations/app-connections/azure), configured for Azure Key Vault.
- Create an [Azure Key Vault Connection](/integrations/app-connections/azure-key-vault)
<Note>
The Azure Key Vault Secret Sync requires the following secrets permissions to be set on the user / service principal
@@ -52,6 +52,7 @@ description: "Learn how to configure a Azure Key Vault Sync for Infisical."
- **Import Secrets (Prioritize Infisical)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Infisical over Secrets Manager when keys conflict.
- **Import Secrets (Prioritize Azure Key Vault)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Secrets Manager over Infisical when keys conflict.
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
6. Configure the **Details** of your Azure Key Vault Sync, then click **Next**.
![Configure Details](/images/secret-syncs/azure-key-vault/vault-details.png)

1
docs/integrations/secret-syncs/databricks.mdx
View File

@@ -47,6 +47,7 @@ description: "Learn how to configure a Databricks Sync for Infisical."
Databricks does not support importing secrets.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
6. Configure the **Details** of your Databricks Sync, then click **Next**.
![Configure Details](/images/secret-syncs/databricks/databricks-details.png)

1
docs/integrations/secret-syncs/gcp-secret-manager.mdx
View File

@@ -43,6 +43,7 @@ description: "Learn how to configure a GCP Secret Manager Sync for Infisical."
- **Import Secrets (Prioritize Infisical)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Infisical over GCP Secret Manager when keys conflict.
- **Import Secrets (Prioritize GCP Secret Manager)**: Imports secrets from the destination endpoint before syncing, prioritizing values from GCP Secret Manager over Infisical when keys conflict.
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
6. Configure the **Details** of your GCP Secret Manager Sync, then click **Next**.
![Configure Details](/images/secret-syncs/gcp-secret-manager/gcp-secret-manager-details.png)

1
docs/integrations/secret-syncs/github.mdx
View File

@@ -63,6 +63,7 @@ description: "Learn how to configure a GitHub Sync for Infisical."
GitHub does not support importing secrets.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
6. Configure the **Details** of your GitHub Sync, then click **Next**.
![Configure Details](/images/secret-syncs/github/github-details.png)

157
docs/integrations/secret-syncs/humanitec.mdx Normal file
View File

@@ -0,0 +1,157 @@
---
title: "Humanitec Sync"
description: "Learn how to configure a Humanitec Sync for Infisical."
---
**Prerequisites:**
- Set up and add secrets to [Infisical Cloud](https://app.infisical.com)
- Create a [Humanitec Connection](/integrations/app-connections/humanitec)
<Tabs>
<Tab title="Infisical UI">
1. Navigate to **Project** > **Integrations** and select the **Secret Syncs** tab. Click on the **Add Sync** button.
![Secret Syncs Tab](/images/secret-syncs/general/secret-sync-tab.png)
2. Select the **Humanitec** option.
![Select Humanitec](/images/secret-syncs/humanitec/select-humanitec-option.png)
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
![Configure Source](/images/secret-syncs/humanitec/humanitec-source.png)
- **Environment**: The project environment to retrieve secrets from.
- **Secret Path**: The folder path to retrieve secrets from.
<Tip>
If you need to sync secrets from multiple folder locations, check out [secret imports](/documentation/platform/secret-reference#secret-imports).
</Tip>
4. Configure the **Destination** to where secrets should be deployed, then click **Next**.
![Configure Destination](/images/secret-syncs/humanitec/humanitec-destination.png)
- **Humanitec Connection**: The Humanitec Connection to authenticate with.
- **Scope**: The Humanitec secret scope to sync secrets to.
- **Application**: Sync secrets to a specific application.
- **Environment**: Sync secrets to a specific environment of an application.
<p class="height:1px" />
The remaining fields are determined by the selected **Scope**:
<AccordionGroup>
<Accordion title="Application">
- **Organization**: The organization to deploy secrets to.
- **App**: The application to deploy secrets to.
</Accordion>
<Accordion title="Environment">
- **Organization**: The organization to deploy secrets to.
- **App**: The application to deploy secrets to.
- **Environment**: The environment to deploy secrets to.
</Accordion>
</AccordionGroup>
5. Configure the **Sync Options** to specify how secrets should be synced, then click **Next**.
![Configure Options](/images/secret-syncs/humanitec/humanitec-options.png)
- **Initial Sync Behavior**: Determines how Infisical should resolve the initial sync.
- **Overwrite Destination Secrets**: Removes any secrets at the destination endpoint not present in Infisical.
<Note>
Humanitec does not support importing secrets.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
6. Configure the **Details** of your Humanitec Sync, then click **Next**.
![Configure Details](/images/secret-syncs/humanitec/humanitec-details.png)
- **Name**: The name of your sync. Must be slug-friendly.
- **Description**: An optional description for your sync.
7. Review your Humanitec Sync configuration, then click **Create Sync**.
![Confirm Configuration](/images/secret-syncs/humanitec/humanitec-review.png)
8. If enabled, your Humanitec Sync will begin syncing your secrets to the destination endpoint.
![Sync Secrets](/images/secret-syncs/humanitec/humanitec-created.png)
</Tab>
<Tab title="API">
To create an **Humanitec Sync**, make an API request to the [Create Humanitec Sync](/api-reference/endpoints/secret-syncs/humanitec/create) API endpoint.
### Sample request
```bash Request
curl --request POST \
--url https://app.infisical.com/api/v1/secret-syncs/humanitec \
--header 'Content-Type: application/json' \
--data '{
"name": "my-humanitec-sync",
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"description": "an example sync",
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"environment": "dev",
"secretPath": "/my-secrets",
"isEnabled": true,
"syncOptions": {
"initialSyncBehavior": "overwrite-destination"
},
"destinationConfig": {
"scope": "application",
"app": "my-app",
"environment": "development"
}
}'
```
### Sample response
```bash Response
{
"secretSync": {
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"name": "my-humanitec-sync",
"description": "an example sync",
"isEnabled": true,
"version": 1,
"folderId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"createdAt": "2023-11-07T05:31:56Z",
"updatedAt": "2023-11-07T05:31:56Z",
"syncStatus": "succeeded",
"lastSyncJobId": "123",
"lastSyncMessage": null,
"lastSyncedAt": "2023-11-07T05:31:56Z",
"importStatus": null,
"lastImportJobId": null,
"lastImportMessage": null,
"lastImportedAt": null,
"removeStatus": null,
"lastRemoveJobId": null,
"lastRemoveMessage": null,
"lastRemovedAt": null,
"syncOptions": {
"initialSyncBehavior": "overwrite-destination"
},
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"connection": {
"app": "humanitec",
"name": "my-humanitec-connection",
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
},
"environment": {
"slug": "dev",
"name": "Development",
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
},
"folder": {
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"path": "/my-secrets"
},
"destination": "humanitec",
"destinationConfig": {
"scope": "application",
"org": "my-organization",
"app": "my-app",
"env": "development"
}
}
}
```
</Tab>
</Tabs>

2
docs/internals/security.mdx
View File

@@ -103,7 +103,7 @@ With standby regions and automated failovers in place, Infisical Cloud faces min
Infisical hires external third parties to perform regular security assessment and penetration testing of the platform.
Most recently, Infisical commissioned cybersecurity firm [Oneleet](https://www.oneleet.com) to perform a full-coverage, gray box penetration test against the platform's entire attack surface to identify vulnerabilities according to industry standards (OWASP, ASVS, WSTG, TOP-10, etc.).
Most recently, Infisical commissioned cybersecurity firm [Cure53](https://cure53.de/) to perform a full-coverage, gray box penetration test against the platform's entire attack surface to identify vulnerabilities according to industry standards (OWASP, ASVS, WSTG, TOP-10, etc.).
Please email security@infisical.com to request any reports including a letter of attestation for the conducted penetration test.

40
docs/mint.json
View File

@@ -150,7 +150,14 @@
"pages": [
"documentation/platform/access-controls/overview",
"documentation/platform/access-controls/role-based-access-controls",
"documentation/platform/access-controls/attribute-based-access-controls",
{
"group": "Attribute based access controls",
"pages": [
"documentation/platform/access-controls/abac/overview",
"documentation/platform/access-controls/abac/managing-user-metadata",
"documentation/platform/access-controls/abac/managing-machine-identity-attributes"
]
},
"documentation/platform/access-controls/additional-privileges",
"documentation/platform/access-controls/temporary-access",
"documentation/platform/access-controls/access-requests",
@@ -408,7 +415,8 @@
"integrations/app-connections/azure-key-vault",
"integrations/app-connections/databricks",
"integrations/app-connections/gcp",
"integrations/app-connections/github"
"integrations/app-connections/github",
"integrations/app-connections/humanitec"
]
}
]
@@ -426,7 +434,8 @@
"integrations/secret-syncs/azure-key-vault",
"integrations/secret-syncs/databricks",
"integrations/secret-syncs/gcp-secret-manager",
"integrations/secret-syncs/github"
"integrations/secret-syncs/github",
"integrations/secret-syncs/humanitec"
]
}
]
@@ -898,6 +907,18 @@
"api-reference/endpoints/app-connections/github/update",
"api-reference/endpoints/app-connections/github/delete"
]
},
{
"group": "Humanitec",
"pages": [
"api-reference/endpoints/app-connections/humanitec/list",
"api-reference/endpoints/app-connections/humanitec/available",
"api-reference/endpoints/app-connections/humanitec/get-by-id",
"api-reference/endpoints/app-connections/humanitec/get-by-name",
"api-reference/endpoints/app-connections/humanitec/create",
"api-reference/endpoints/app-connections/humanitec/update",
"api-reference/endpoints/app-connections/humanitec/delete"
]
}
]
},
@@ -1001,6 +1022,19 @@
"api-reference/endpoints/secret-syncs/github/sync-secrets",
"api-reference/endpoints/secret-syncs/github/remove-secrets"
]
},
{
"group": "Humanitec",
"pages": [
"api-reference/endpoints/secret-syncs/humanitec/list",
"api-reference/endpoints/secret-syncs/humanitec/get-by-id",
"api-reference/endpoints/secret-syncs/humanitec/get-by-name",
"api-reference/endpoints/secret-syncs/humanitec/create",
"api-reference/endpoints/secret-syncs/humanitec/update",
"api-reference/endpoints/secret-syncs/humanitec/delete",
"api-reference/endpoints/secret-syncs/humanitec/sync-secrets",
"api-reference/endpoints/secret-syncs/humanitec/remove-secrets"
]
}
]
},