Merge branch 'heads/main' into daniel/k8s-dynamic-secrets
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: "Create"
|
||||
openapi: "POST /api/v1/app-connections/aws"
|
||||
---
|
||||
|
||||
<Note>
|
||||
Check out the configuration docs for [AWS Connections](/integrations/app-connections/aws) to learn how to obtain
|
||||
the required credentials.
|
||||
</Note>
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Delete"
|
||||
openapi: "DELETE /api/v1/app-connections/aws/{connectionId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get by ID"
|
||||
openapi: "GET /api/v1/app-connections/aws/{connectionId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get by Name"
|
||||
openapi: "GET /api/v1/app-connections/aws/name/{connectionName}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "List"
|
||||
openapi: "GET /api/v1/app-connections/aws"
|
||||
---
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: "Update"
|
||||
openapi: "PATCH /api/v1/app-connections/aws/{connectionId}"
|
||||
---
|
||||
|
||||
<Note>
|
||||
Check out the configuration docs for [AWS Connections](/integrations/app-connections/aws) to learn how to obtain
|
||||
the required credentials.
|
||||
</Note>
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: "Create"
|
||||
openapi: "POST /api/v1/app-connections/github"
|
||||
---
|
||||
|
||||
<Note>
|
||||
GitHub Connections must be created through the Infisical UI.
|
||||
Check out the configuration docs for [GitHub Connections](/integrations/app-connections/github) for a step-by-step
|
||||
guide.
|
||||
</Note>
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Delete"
|
||||
openapi: "DELETE /api/v1/app-connections/github/{connectionId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get by ID"
|
||||
openapi: "GET /api/v1/app-connections/github/{connectionId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get by Name"
|
||||
openapi: "GET /api/v1/app-connections/github/name/{connectionName}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "List"
|
||||
openapi: "GET /api/v1/app-connections/github"
|
||||
---
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: "Update"
|
||||
openapi: "PATCH /api/v1/app-connections/github/{connectionId}"
|
||||
---
|
||||
|
||||
<Note>
|
||||
GitHub Connections must be updated through the Infisical UI.
|
||||
Check out the configuration docs for [GitHub Connections](/integrations/app-connections/github) for a step-by-step
|
||||
guide.
|
||||
</Note>
|
||||
4
docs/api-reference/endpoints/app-connections/list.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "List"
|
||||
openapi: "GET /api/v1/app-connections"
|
||||
---
|
||||
4
docs/api-reference/endpoints/app-connections/options.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Options"
|
||||
openapi: "GET /api/v1/app-connections/options"
|
||||
---
|
||||
4
docs/api-reference/endpoints/jwt-auth/attach.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Attach"
|
||||
openapi: "POST /api/v1/auth/jwt-auth/identities/{identityId}"
|
||||
---
|
||||
4
docs/api-reference/endpoints/jwt-auth/login.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Login"
|
||||
openapi: "POST /api/v1/auth/jwt-auth/login"
|
||||
---
|
||||
4
docs/api-reference/endpoints/jwt-auth/retrieve.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Retrieve"
|
||||
openapi: "GET /api/v1/auth/jwt-auth/identities/{identityId}"
|
||||
---
|
||||
4
docs/api-reference/endpoints/jwt-auth/revoke.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Revoke"
|
||||
openapi: "DELETE /api/v1/auth/jwt-auth/identities/{identityId}"
|
||||
---
|
||||
4
docs/api-reference/endpoints/jwt-auth/update.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Update"
|
||||
openapi: "PATCH /api/v1/auth/jwt-auth/identities/{identityId}"
|
||||
---
|
||||
4
docs/api-reference/endpoints/ssh/ca/create.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Create"
|
||||
openapi: "POST /api/v1/ssh/ca"
|
||||
---
|
||||
4
docs/api-reference/endpoints/ssh/ca/delete.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Delete"
|
||||
openapi: "DELETE /api/v1/ssh/ca/{sshCaId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "List templates"
|
||||
openapi: "GET /api/v1/ssh/ca/{sshCaId}/certificate-templates"
|
||||
---
|
||||
4
docs/api-reference/endpoints/ssh/ca/list.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "List"
|
||||
openapi: "GET /api/v2/workspace/{projectId}/ssh-cas"
|
||||
---
|
||||
4
docs/api-reference/endpoints/ssh/ca/public-key.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Retrieve public key"
|
||||
openapi: "GET /api/v1/ssh/ca/{sshCaId}/public-key"
|
||||
---
|
||||
4
docs/api-reference/endpoints/ssh/ca/read.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Retrieve"
|
||||
openapi: "GET /api/v1/ssh/ca/{sshCaId}"
|
||||
---
|
||||
4
docs/api-reference/endpoints/ssh/ca/update.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Update"
|
||||
openapi: "PATCH /api/v1/ssh/ca/{sshCaId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Create"
|
||||
openapi: "POST /api/v1/ssh/certificate-templates"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Delete"
|
||||
openapi: "DELETE /api/v1/ssh/certificate-templates/{certificateTemplateId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "List"
|
||||
openapi: "GET /api/v2/workspace/{projectId}/ssh-certificate-templates"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Retrieve"
|
||||
openapi: "GET /api/v1/ssh/certificate-templates/{certificateTemplateId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Update"
|
||||
openapi: "PATCH /api/v1/ssh/certificate-templates/{certificateTemplateId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Issue SSH Credentials"
|
||||
openapi: "POST /api/v1/ssh/certificates/issue"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Sign SSH Public Key"
|
||||
openapi: "POST /api/v1/ssh/certificates/sign"
|
||||
---
|
||||
116
docs/cli/commands/ssh.mdx
Normal file
@@ -0,0 +1,116 @@
|
||||
---
|
||||
title: "infisical ssh"
|
||||
description: "Generate SSH credentials with the CLI"
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
[Infisical SSH](/documentation/platform/ssh) lets you issue SSH credentials to clients to provide short-lived, secure SSH access to infrastructure.
|
||||
|
||||
This command enables you to obtain SSH credentials used to access a remote host; we recommend using the `issue-credentials` sub-command to generate dynamic SSH credentials for each SSH session.
|
||||
|
||||
### Sub-commands
|
||||
|
||||
<Accordion title="infisical ssh issue-credentials">
|
||||
This command is used to issue SSH credentials (SSH certificate, public key, and private key) against a certificate template.
|
||||
|
||||
We recommend using the `--addToAgent` flag to automatically load issued SSH credentials to the SSH agent.
|
||||
|
||||
```bash
|
||||
$ infisical ssh issue-credentials --certificateTemplateId=<certificate-template-id> --principals=<principals> --addToAgent
|
||||
```
|
||||
|
||||
### Flags
|
||||
<Accordion title="--certificateTemplateId">
|
||||
The ID of the SSH certificate template to issue SSH credentials for.
|
||||
</Accordion>
|
||||
<Accordion title="--principals">
|
||||
A comma-separated list of principals (i.e. usernames like `ec2-user` or hostnames) to issue SSH credentials for.
|
||||
</Accordion>
|
||||
<Accordion title="--addToAgent">
|
||||
Whether to add issued SSH credentials to the SSH agent.
|
||||
|
||||
Default value: `false`
|
||||
|
||||
Note that either the `--outFilePath` or `--addToAgent` flag must be set for the sub-command to execute successfully.
|
||||
</Accordion>
|
||||
<Accordion title="--outFilePath">
|
||||
The path to write the SSH credentials to such as `~/.ssh`, `./some_folder`, `./some_folder/id_rsa-cert.pub`. If not provided, the credentials will be saved to the current working directory where the command is run.
|
||||
|
||||
Note that either the `--outFilePath` or `--addToAgent` flag must be set for the sub-command to execute successfully.
|
||||
</Accordion>
|
||||
<Accordion title="--keyAlgorithm">
|
||||
The key algorithm to issue SSH credentials for.
|
||||
|
||||
Default value: `RSA_2048`
|
||||
|
||||
Available options: `RSA_2048`, `RSA_4096`, `EC_prime256v1`, `EC_secp384r1`.
|
||||
</Accordion>
|
||||
<Accordion title="--certType">
|
||||
The certificate type to issue SSH credentials for.
|
||||
|
||||
Default value: `user`
|
||||
|
||||
Available options: `user` or `host`
|
||||
</Accordion>
|
||||
<Accordion title="--ttl">
|
||||
The time-to-live (TTL) for the issued SSH certificate (e.g. `2 days`, `1d`, `2h`, `1y`).
|
||||
|
||||
Defaults to the Default TTL value set in the certificate template.
|
||||
</Accordion>
|
||||
<Accordion title="--keyId">
|
||||
A custom Key ID to issue SSH credentials for.
|
||||
|
||||
Defaults to the autogenerated Key ID by Infisical.
|
||||
</Accordion>
|
||||
<Accordion title="--token">
|
||||
An authenticated token to use to issue SSH credentials.
|
||||
</Accordion>
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="infisical ssh sign-key">
|
||||
This command is used to sign an existing SSH public key against a certificate template; the command outputs the corresponding signed SSH certificate.
|
||||
|
||||
```bash
|
||||
$ infisical ssh sign-key --certificateTemplateId=<certificate-template-id> --publicKey=<public-key> --principals=<principals> --outFilePath=<out-file-path>
|
||||
```
|
||||
<Accordion title="--certificateTemplateId">
|
||||
The ID of the SSH certificate template to issue the SSH certificate for.
|
||||
</Accordion>
|
||||
<Accordion title="--publicKey">
|
||||
The public key to sign.
|
||||
|
||||
Note that either the `--publicKey` or `--publicKeyFilePath` flag must be set for the sub-command to execute successfully.
|
||||
</Accordion>
|
||||
<Accordion title="--publicKeyFilePath">
|
||||
The path to the public key file to sign.
|
||||
|
||||
Note that either the `--publicKey` or `--publicKeyFilePath` flag must be set for the sub-command to execute successfully.
|
||||
</Accordion>
|
||||
<Accordion title="--principals">
|
||||
A comma-separated list of principals (i.e. usernames like `ec2-user` or hostnames) to issue SSH credentials for.
|
||||
</Accordion>
|
||||
<Accordion title="--outFilePath">
|
||||
The path to write the SSH certificate to such as `~/.ssh/id_rsa-cert.pub`; the specified file must have the `.pub` extension. If not provided, the credentials will be saved to the directory of the specified `--publicKeyFilePath` or the current working directory where the command is run.
|
||||
</Accordion>
|
||||
<Accordion title="--certType">
|
||||
The certificate type to issue SSH credentials for.
|
||||
|
||||
Default value: `user`
|
||||
|
||||
Available options: `user` or `host`
|
||||
</Accordion>
|
||||
<Accordion title="--ttl">
|
||||
The time-to-live (TTL) for the issued SSH certificate (e.g. `2 days`, `1d`, `2h`, `1y`).
|
||||
|
||||
Defaults to the Default TTL value set in the certificate template.
|
||||
</Accordion>
|
||||
<Accordion title="--keyId">
|
||||
A custom Key ID to issue SSH credentials for.
|
||||
|
||||
Defaults to the autogenerated Key ID by Infisical.
|
||||
</Accordion>
|
||||
<Accordion title="--token">
|
||||
An authenticated token to use to issue SSH credentials.
|
||||
</Accordion>
|
||||
</Accordion>
|
||||
169
docs/documentation/platform/identities/jwt-auth.mdx
Normal file
@@ -0,0 +1,169 @@
|
||||
---
|
||||
title: JWT Auth
|
||||
description: "Learn how to authenticate with Infisical using JWT-based authentication."
|
||||
---
|
||||
|
||||
**JWT Auth** is a platform-agnostic authentication method that validates JSON Web Tokens (JWTs) issued by your JWT issuer or authentication system, allowing secure authentication from any platform or environment that can obtain valid JWTs.
|
||||
|
||||
## Diagram
|
||||
|
||||
The following sequence diagram illustrates the JWT Auth workflow for authenticating with Infisical.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Client as Client Application
|
||||
participant Issuer as JWT Issuer
|
||||
participant Infis as Infisical
|
||||
|
||||
Client->>Issuer: Step 1: Request JWT token
|
||||
Issuer-->>Client: Return signed JWT with claims
|
||||
|
||||
Note over Client,Infis: Step 2: Login Operation
|
||||
Client->>Infis: Send signed JWT to /api/v1/auth/jwt-auth/login
|
||||
|
||||
Note over Infis: Step 3: JWT Validation
|
||||
Infis->>Infis: Validate JWT signature using configured public keys or JWKS
|
||||
Infis->>Infis: Verify required claims (aud, sub, iss)
|
||||
|
||||
Note over Infis: Step 4: Token Generation
|
||||
Infis->>Client: Return short-lived access token
|
||||
|
||||
Note over Client,Infis: Step 5: Access Infisical API with Token
|
||||
Client->>Infis: Make authenticated requests using the short-lived access token
|
||||
```
|
||||
|
||||
## Concept
|
||||
|
||||
At a high-level, Infisical authenticates a client by verifying the JWT and checking that it meets specific requirements (e.g. it is signed by a trusted key) at the `/api/v1/auth/jwt-auth/login` endpoint. If successful, then Infisical returns a short-lived access token that can be used to make authenticated requests to the Infisical API.
|
||||
|
||||
To be more specific:
|
||||
|
||||
1. The client requests a JWT from their JWT issuer.
|
||||
2. The fetched JWT is sent to Infisical at the `/api/v1/auth/jwt-auth/login` endpoint.
|
||||
3. Infisical validates the JWT signature using either:
|
||||
- Pre-configured public keys (Static configuration)
|
||||
- Public keys fetched from a JWKS endpoint (JWKS configuration)
|
||||
4. Infisical verifies that the configured claims match in the token. This includes standard claims like subject, audience, and issuer, as well as any additional custom claims specified in the configuration.
|
||||
5. If all is well, Infisical returns a short-lived access token that the client can use to make authenticated requests to the Infisical API.
|
||||
|
||||
<Note>
|
||||
For JWKS configuration, Infisical needs network-level access to the configured
|
||||
JWKS endpoint.
|
||||
</Note>
|
||||
|
||||
## Guide
|
||||
|
||||
In the following steps, we explore how to create and use identities to access the Infisical API using the JWT authentication method.
|
||||
|
||||
<Steps>
|
||||
<Step title="Creating an identity">
|
||||
To create an identity, head to your Organization Settings > Access Control > Machine Identities and press **Create identity**.
|
||||
|
||||

|
||||
|
||||
When creating an identity, you specify an organization level [role](/documentation/platform/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
|
||||
|
||||

|
||||
|
||||
Now input a few details for your new identity. Here's some guidance for each field:
|
||||
|
||||
- Name (required): A friendly name for the identity.
|
||||
- Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
|
||||
|
||||
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
|
||||
|
||||

|
||||
|
||||
Since the identity has been configured with Universal Auth by default, you should re-configure it to use JWT Auth instead. To do this, press to edit the **Authentication** section,
|
||||
remove the existing Universal Auth configuration, and add a new JWT Auth configuration onto the identity.
|
||||
|
||||

|
||||
|
||||

|
||||

|
||||
|
||||
<Warning>Restrict access by properly configuring the JWT validation settings.</Warning>
|
||||
|
||||
Here's some more guidance for each field:
|
||||
|
||||
**Static configuration**:
|
||||
- Public Keys: One or more PEM-encoded public keys (RSA or ECDSA) used to verify JWT signatures. Each key must include the proper BEGIN/END markers.
|
||||
|
||||
**JWKS configuration**:
|
||||
- JWKS URL: The endpoint URL that serves your JSON Web Key Sets (JWKS). This endpoint must provide the public keys used for JWT signature verification.
|
||||
- JWKS CA Certificate: Optional PEM-encoded CA certificate used for validating the TLS connection to the JWKS endpoint.
|
||||
|
||||
**Common fields for both configurations**:
|
||||
- Issuer: The unique identifier of the JWT provider. This value is used to verify the iss (issuer) claim in the JWT.
|
||||
- Audiences: A list of intended recipients. This value is checked against the aud (audience) claim in the token.
|
||||
- Subject: The expected principal that is the subject of the JWT. This value is checked against the sub (subject) claim in the token.
|
||||
- Claims: Additional claims that must be present in the JWT for it to be valid. You can specify required claim names and their expected values.
|
||||
- Access Token TTL (default is `2592000` equivalent to 30 days): The lifetime for an access token in seconds. This value will be referenced at renewal time.
|
||||
- Access Token Max TTL (default is `2592000` equivalent to 30 days): The maximum lifetime for an access token in seconds. This value will be referenced at renewal time.
|
||||
- Access Token Max Number of Uses (default is `0`): The maximum number of times that an access token can be used; a value of `0` implies infinite number of uses.
|
||||
- Access Token Trusted IPs: The IPs or CIDR ranges that access tokens can be used from. By default, each token is given the `0.0.0.0/0`, allowing usage from any network address.
|
||||
|
||||
<Info>The `subject`, `audiences`, and `claims` fields support glob pattern matching; however, we highly recommend using hardcoded values whenever possible.</Info>
|
||||
</Step>
|
||||
|
||||
<Step title="Adding an identity to a project">
|
||||
To enable the identity to access project-level resources such as secrets within a specific project, you should add it to that project.
|
||||
|
||||
To do this, head over to the project you want to add the identity to and go to Project Settings > Access Control > Machine Identities and press **Add identity**.
|
||||
|
||||
Next, select the identity you want to add to the project and the project level role you want to allow it to assume. The project role assigned will determine what project level resources this identity can have access to.
|
||||
|
||||

|
||||
|
||||

|
||||
</Step>
|
||||
|
||||
<Step title="Accessing the Infisical API with the identity">
|
||||
To access the Infisical API as the identity, you will need to obtain a JWT from your JWT issuer that meets the validation requirements configured in step 2.
|
||||
|
||||
Once you have obtained a valid JWT, you can use it to authenticate with Infisical at the `/api/v1/auth/jwt-auth/login` endpoint.
|
||||
|
||||
We provide a code example below of how you might use the JWT to authenticate with Infisical to gain access to the [Infisical API](/api-reference/overview/introduction).
|
||||
|
||||
<Accordion
|
||||
title="Sample code for inside an application"
|
||||
>
|
||||
The shown example uses Node.js but you can use any other language to authenticate with Infisical using your JWT.
|
||||
|
||||
```javascript
|
||||
try {
|
||||
// Obtain JWT from your issuer
|
||||
const jwt = "<your-jwt-token>";
|
||||
|
||||
const infisicalUrl = "https://app.infisical.com"; // or your self-hosted Infisical URL
|
||||
const identityId = "<your-identity-id>";
|
||||
|
||||
const { data } = await axios.post(
|
||||
`{infisicalUrl}/api/v1/auth/jwt-auth/login`,
|
||||
{
|
||||
identityId,
|
||||
jwt,
|
||||
}
|
||||
);
|
||||
|
||||
console.log("result data: ", data); // access token here
|
||||
} catch(err) {
|
||||
console.error(err);
|
||||
}
|
||||
```
|
||||
</Accordion>
|
||||
|
||||
<Tip>
|
||||
We recommend using one of Infisical's clients like SDKs or the Infisical Agent to authenticate with Infisical using JWT Auth as they handle the authentication process for you.
|
||||
</Tip>
|
||||
|
||||
<Note>
|
||||
Each identity access token has a time-to-live (TTL) which you can infer from the response of the login operation;
|
||||
the default TTL is `2592000` seconds (30 days) which can be adjusted in the configuration.
|
||||
|
||||
If an identity access token exceeds its max TTL or maximum number of uses, it can no longer authenticate with the Infisical API. In this case,
|
||||
a new access token should be obtained by performing another login operation with a valid JWT.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
210
docs/documentation/platform/ssh.mdx
Normal file
@@ -0,0 +1,210 @@
|
||||
---
|
||||
title: "Infisical SSH"
|
||||
sidebarTitle: "Infisical SSH"
|
||||
description: "Learn how to generate SSH credentials to provide secure and centralized SSH access control for your infrastructure."
|
||||
---
|
||||
|
||||
## Concept
|
||||
|
||||
Infisical can be used to issue SSH credentials to clients to provide short-lived, secure SSH access to infrastructure;
|
||||
this improves on many limitations of traditional SSH key-based authentication via mitigation of private key compromise, static key management,
|
||||
unauthorized access, and SSH key sprawl.
|
||||
|
||||
The following concepts are useful to know when working with Infisical SSH:
|
||||
|
||||
- SSH Certificate Authority (CA): A trusted authority that issues SSH certificates.
|
||||
- Certificate Template: A set of policies bound to a SSH CA for certificates issued under that template; a CA can possess multiple templates, each with different policies for a different purpose (e.g. for admin versus developer access).
|
||||
- SSH Certificate: A short-lived, credential issued by the SSH CA granting time-bound access to infrastructure.
|
||||
|
||||
<div align="center">
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[SSH CA]
|
||||
A --> B[Certificate Template A]
|
||||
A --> C[Certificate Template N]
|
||||
B --> D[SSH Certificate A]
|
||||
C --> E[SSH Certificate N]
|
||||
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
When using Infisical SSH to provision client access to a remote host, an operator must create a SSH CA in Infisical; a certificate template under it,
|
||||
specifying policies such as allowed users that can be requested under that template by a client; and configure the host to trust certificates issued by the Infisical SSH CA.
|
||||
|
||||
When a client needs access to a host, they authenticate with Infisical and request a SSH certificate (and optionally key pair)
|
||||
to be used to access the host for a time-bound session as part of the SSH operation.
|
||||
|
||||
## Client Workflow
|
||||
|
||||
The following sequence diagram illustrates the client workflow for accessing a remote host using an SSH certificate (and optionally key pair)
|
||||
supplied by Infisical.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Client as Client
|
||||
participant Infisical as Infisical (SSH CA)
|
||||
participant Host as Remote Host
|
||||
|
||||
Note over Client,Client: Step 1: Client Authentication with Infisical
|
||||
Client->>Infisical: Send credential(s) to authenticate with Infisical
|
||||
|
||||
Infisical-->>Client: Return access token
|
||||
|
||||
Note over Client,Infisical: Step 2: SSH Certificate Request
|
||||
Client->>Infisical: Make authenticated request for SSH certificate via either /api/v1/ssh/issue or /api/v1/ssh/sign
|
||||
|
||||
Infisical-->>Client: Return signed SSH certificate (and optionally key pair)
|
||||
|
||||
Note over Client,Client: Step 3: SSH Operation
|
||||
Client->>Host: SSH into Host using the SSH certificate
|
||||
|
||||
Host-->>Client: Grant access to the host
|
||||
```
|
||||
|
||||
At a high-level, Infisical issues a signed SSH certificate to a client that can be used to access a remote host.
|
||||
|
||||
To be more specific:
|
||||
|
||||
1. The client authenticates with Infisical; this can be done using a machine identity [authentication method](/documentation/platform/identities/machine-identities) or a user [authentication method](/documentation/platform/identities/user-identities).
|
||||
2. The client makes an authenticated request for an SSH certificate via either the `/api/v1/ssh/issue` or `/api/v1/ssh/sign` endpoints. Note that if the client wishes to use an existing SSH key pair, it can use the `/api/v1/ssh/sign` endpoint; otherwise, it can use the `/api/v1/ssh/issue` endpoint to have Infisical issue a new SSH key pair in conjunction with the certificate.
|
||||
3. The client uses the issued SSH certificate (and potentially SSH key pair) to temporarily access the host.
|
||||
|
||||
<Note>
|
||||
Note that the workflow above requires an operator to perform additional
|
||||
configuration on the remote host to trust SSH certificates issued by
|
||||
Infisical.
|
||||
</Note>
|
||||
|
||||
## Guide to Configuring Infisical SSH
|
||||
|
||||
In the following steps, we explore how to configure Infisical SSH to start issuing SSH certificates to clients as well as a remote host to trust these certificates
|
||||
as part of the SSH operation.
|
||||
|
||||
<Steps>
|
||||
<Step title="Configuring Infisical SSH">
|
||||
1.1. Start by creating a SSH project in the SSH tab of your organization.
|
||||
|
||||

|
||||
|
||||
1.2. Next, create a CA in the **Certificate Authorities** tab of the
|
||||
project.
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
Here's some guidance on each field:
|
||||
|
||||
- Friendly Name: A friendly name for the CA; this is only for display.
|
||||
- Key Algorithm: The type of public key algorithm and size, in bits, of the key pair for the CA. Supported key algorithms are `RSA 2048`, `RSA 4096`, `ECDSA P-256`, and `ECDSA P-384` with the default being `RSA 2048`.
|
||||
|
||||
1.3. Next, create a certificate template in the **Certificate Templates** section of the newly-created CA.
|
||||
|
||||
A certificate template is a set of policies for certificates issued under that template; each template is bound to a specific CA.
|
||||
|
||||
With certificate templates, you can specify, for example, that certificates issued under a template are only allowed for users with a specific username like `ec2-user` or perhaps that the max TTL requested cannot exceed 1 year.
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
Here's some guidance on each field:
|
||||
|
||||
- SSH Template Name: A name for the certificate template; this must be a valid slug.
|
||||
- Allowed Users: A comma-separated list of valid usernames (e.g. `ec2-user`) on the remote host for which a client can request a certificate for. If you wish to allow a client to request a certificate for any username, set this to `*`; alternatively, if left blank, the template will not allow issuance of certificates under any username.
|
||||
- Allowed Hosts: A comma-separated list of valid hostnames/domains on the remote host for which a client can request a certificate for. Each item in the list can be either a wildcard hostname (e.g. `*.acme.com`), a specific hostname (e.g. `example.com`), an IPv4 address (e.g. `192.168.1.1`), or an IPv6 address. If left empty, the template will not allow any hostnames; if set to `*`, the template will allow any hostname.
|
||||
- Default TTL: The default Time-to-Live (TTL) for certificates issued under this template when a client does not explicitly specify a TTL in the certificate request.
|
||||
- Max TTL: The maximum TTL for certificates issued under this template.
|
||||
- Allow User Certificates: Whether or not to allow issuance of user certificates.
|
||||
- Allow Host Certificates: Whether or not to allow issuance of host certificates.
|
||||
- Allow Custom Key IDs: Whether or not to allow clients to specify a custom key ID to be included on the certificate as part of the certificate request.
|
||||
|
||||
1.4. Finally, add the user(s) you wish to be able to request a SSH certificate to the SSH project through the **Access Control** tab.
|
||||
|
||||
</Step>
|
||||
<Step title="Configuring the remote host">
|
||||
|
||||
2.1. Begin by downloading the CA's public key from the CA's details section.
|
||||
|
||||

|
||||
|
||||
<Note>
|
||||
The CA's public key can also be retrieved programmatically via API by making a `GET` request to the `/ssh/ca/<ca-id>/public-key` endpoint.
|
||||
</Note>
|
||||
|
||||
2.2. Next, create a file containing this public key in the SSH folder of the remote host; we'll call the file `ca.pub`.
|
||||
|
||||
This would result in the file at the path `/etc/ssh/ca.pub`.
|
||||
|
||||
2.3. Next, add the following lines to the `/etc/ssh/sshd_config` file on the remote host.
|
||||
|
||||
```bash
|
||||
TrustedUserCAKeys /etc/ssh/ca.pub
|
||||
|
||||
PubkeyAcceptedKeyTypes=+ssh-rsa,ssh-rsa-cert-v01@openssh.com
|
||||
```
|
||||
|
||||
2.4. Finally, reload the SSH daemon on the remote host to apply the changes.
|
||||
|
||||
```bash
|
||||
sudo systemctl reload sshd
|
||||
```
|
||||
|
||||
At this point, the remote host is configured to trust SSH certificates issued by the Infisical SSH CA.
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Guide to Using Infisical SSH to Access a Host
|
||||
|
||||
We show how to obtain a SSH certificate and use it for a client to access a host via CLI:
|
||||
|
||||
<Note>
|
||||
The subsequent guide assumes the following prerequisites:
|
||||
|
||||
- SSH Agent is running: The `ssh-agent` must be actively running on the host machine.
|
||||
- OpenSSH is installed: The system should have OpenSSH installed; this includes
|
||||
both the `ssh` client and `ssh-agent`.
|
||||
- `SSH_AUTH_SOCK` environment variable
|
||||
is set; the `SSH_AUTH_SOCK` variable should point to the UNIX socket that
|
||||
`ssh-agent` uses for communication.
|
||||
|
||||
</Note>
|
||||
|
||||
<Steps>
|
||||
<Step title="Authenticate with Infisical">
|
||||
|
||||
```bash
|
||||
infisical login
|
||||
```
|
||||
|
||||
</Step>
|
||||
<Step title="Obtain a SSH certificate and load it into the SSH agent">
|
||||
Run the `infisical ssh issue-credentials` command, specifying the `--addToAgent` flag to automatically load the SSH certificate into the SSH agent.
|
||||
```bash
|
||||
infisical ssh issue-credentials --certificateTemplateId=<certificate-template-id> --principals=<username> --addToAgent
|
||||
```
|
||||
|
||||
Here's some guidance on each flag:
|
||||
|
||||
- `certificateTemplateId`: The ID of the certificate template to use for issuing the SSH certificate.
|
||||
- `principals`: The comma-delimited username(s) or hostname(s) to include in the SSH certificate.
|
||||
|
||||
For fuller documentation on commands and flags supported by the Infisical CLI for SSH, refer to the docs [here](/cli/commands/ssh).
|
||||
|
||||
</Step>
|
||||
<Step title="SSH into the host">
|
||||
Finally, SSH into the desired host; the SSH operation will be performed using the SSH certificate loaded into the SSH agent.
|
||||
|
||||
```bash
|
||||
ssh username@hostname
|
||||
```
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
<Note>
|
||||
Note that the above workflow can be executed via API or other client methods
|
||||
such as SDK.
|
||||
</Note>
|
||||
BIN
docs/images/app-connections/aws/access-key-connection.png
Normal file
|
After Width: | Height: | Size: 957 KiB |
BIN
docs/images/app-connections/aws/assume-role-connection.png
Normal file
|
After Width: | Height: | Size: 957 KiB |
BIN
docs/images/app-connections/aws/create-access-key-method.png
Normal file
|
After Width: | Height: | Size: 598 KiB |
BIN
docs/images/app-connections/aws/create-assume-role-method.png
Normal file
|
After Width: | Height: | Size: 584 KiB |
BIN
docs/images/app-connections/aws/parameter-store-permissions.png
Normal file
|
After Width: | Height: | Size: 306 KiB |
BIN
docs/images/app-connections/aws/secrets-manager-permissions.png
Normal file
|
After Width: | Height: | Size: 311 KiB |
BIN
docs/images/app-connections/aws/select-aws-connection.png
Normal file
|
After Width: | Height: | Size: 584 KiB |
BIN
docs/images/app-connections/general/add-connection.png
Normal file
|
After Width: | Height: | Size: 974 KiB |
BIN
docs/images/app-connections/github/create-github-app-method.png
Normal file
|
After Width: | Height: | Size: 586 KiB |
BIN
docs/images/app-connections/github/create-oauth-method.png
Normal file
|
After Width: | Height: | Size: 580 KiB |
BIN
docs/images/app-connections/github/github-app-connection.png
Normal file
|
After Width: | Height: | Size: 974 KiB |
BIN
docs/images/app-connections/github/install-github-app.png
Normal file
|
After Width: | Height: | Size: 352 KiB |
BIN
docs/images/app-connections/github/oauth-connection.png
Normal file
|
After Width: | Height: | Size: 974 KiB |
BIN
docs/images/app-connections/github/select-github-connection.png
Normal file
|
After Width: | Height: | Size: 562 KiB |
|
Before Width: | Height: | Size: 554 KiB After Width: | Height: | Size: 795 KiB |
|
After Width: | Height: | Size: 493 KiB |
|
Before Width: | Height: | Size: 162 KiB After Width: | Height: | Size: 494 KiB |
|
After Width: | Height: | Size: 537 KiB |
|
After Width: | Height: | Size: 538 KiB |
|
Before Width: | Height: | Size: 339 KiB After Width: | Height: | Size: 555 KiB |
|
After Width: | Height: | Size: 492 KiB |
|
After Width: | Height: | Size: 495 KiB |
BIN
docs/images/platform/ssh/ssh-ca-public-key.png
Normal file
|
After Width: | Height: | Size: 665 KiB |
BIN
docs/images/platform/ssh/ssh-create-ca-1.png
Normal file
|
After Width: | Height: | Size: 597 KiB |
BIN
docs/images/platform/ssh/ssh-create-ca-2.png
Normal file
|
After Width: | Height: | Size: 277 KiB |
BIN
docs/images/platform/ssh/ssh-create-template-1.png
Normal file
|
After Width: | Height: | Size: 665 KiB |
BIN
docs/images/platform/ssh/ssh-create-template-2.png
Normal file
|
After Width: | Height: | Size: 430 KiB |
BIN
docs/images/platform/ssh/ssh-project.png
Normal file
|
After Width: | Height: | Size: 698 KiB |
354
docs/integrations/app-connections/aws.mdx
Normal file
@@ -0,0 +1,354 @@
|
||||
---
|
||||
title: "AWS Connection"
|
||||
description: "Learn how to configure an AWS Connection for Infisical."
|
||||
---
|
||||
|
||||
Infisical supports two methods for connecting to AWS.
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Assume Role (Recommended)">
|
||||
Infisical will assume the provided role in your AWS account securely, without the need to share any credentials.
|
||||
|
||||
**Prerequisites:**
|
||||
|
||||
- Set up and add envars to [Infisical Cloud](https://app.infisical.com)
|
||||
|
||||
<Accordion title="Self-Hosted Instance">
|
||||
To connect your self-hosted Infisical instance with AWS, you need to set up an AWS IAM User account that can assume the configured AWS IAM Role.
|
||||
|
||||
If your instance is deployed on AWS, the aws-sdk will automatically retrieve the credentials. Ensure that you assign the provided permission policy to your deployed instance, such as ECS or EC2.
|
||||
|
||||
The following steps are for instances not deployed on AWS:
|
||||
<Steps>
|
||||
<Step title="Create an IAM User">
|
||||
Navigate to [Create IAM User](https://console.aws.amazon.com/iamv2/home#/users/create) in your AWS Console.
|
||||
</Step>
|
||||
<Step title="Create an Inline Policy">
|
||||
Attach the following inline permission policy to the IAM User to allow it to assume any IAM Roles:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AllowAssumeAnyRole",
|
||||
"Effect": "Allow",
|
||||
"Action": "sts:AssumeRole",
|
||||
"Resource": "arn:aws:iam::*:role/*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
</Step>
|
||||
<Step title="Obtain the IAM User Credentials">
|
||||
Obtain the AWS access key ID and secret access key for your IAM User by navigating to **IAM > Users > [Your User] > Security credentials > Access keys**.
|
||||
|
||||

|
||||

|
||||

|
||||
</Step>
|
||||
<Step title="Set Up Connection Keys">
|
||||
1. Set the access key as **INF_APP_CONNECTION_AWS_CLIENT_ID**.
|
||||
2. Set the secret key as **INF_APP_CONNECTION_AWS_CLIENT_SECRET**.
|
||||
</Step>
|
||||
</Steps>
|
||||
</Accordion>
|
||||
|
||||
<Steps>
|
||||
<Step title="Create the Managing User IAM Role for Infisical">
|
||||
1. Navigate to the [Create IAM Role](https://console.aws.amazon.com/iamv2/home#/roles/create?step=selectEntities) page in your AWS Console.
|
||||

|
||||
|
||||
2. Select **AWS Account** as the **Trusted Entity Type**.
|
||||
3. Choose **Another AWS Account** and enter **381492033652** (Infisical AWS Account ID). This restricts the role to be assumed only by Infisical. If self-hosting, provide your AWS account number instead.
|
||||
4. Optionally, enable **Require external ID** and enter your **Organization ID** to further enhance security.
|
||||
</Step>
|
||||
|
||||
<Step title="Add Required Permissions for the IAM Role">
|
||||
Depending on your use case, add one or more of the following policies to your IAM Role:
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Secrets Sync">
|
||||
<AccordionGroup>
|
||||
<Accordion title="AWS Secrets Manager">
|
||||
Use the following custom policy to grant the minimum permissions required by Infisical to sync secrets to AWS Secrets Manager:
|
||||
|
||||

|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AllowSecretsManagerAccess",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"secretsmanager:GetSecretValue",
|
||||
"secretsmanager:CreateSecret",
|
||||
"secretsmanager:UpdateSecret",
|
||||
"secretsmanager:DescribeSecret",
|
||||
"secretsmanager:TagResource",
|
||||
"secretsmanager:UntagResource",
|
||||
"kms:ListKeys",
|
||||
"kms:ListAliases",
|
||||
"kms:Encrypt",
|
||||
"kms:Decrypt"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
</Accordion>
|
||||
<Accordion title="AWS Parameter Store">
|
||||
Use the following custom policy to grant the minimum permissions required by Infisical to sync secrets to AWS Parameter Store:
|
||||
|
||||

|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AllowSSMAccess",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ssm:PutParameter",
|
||||
"ssm:DeleteParameter",
|
||||
"ssm:GetParameters",
|
||||
"ssm:GetParametersByPath",
|
||||
"ssm:DescribeParameters",
|
||||
"ssm:DeleteParameters",
|
||||
"ssm:AddTagsToResource", // if you need to add tags to secrets
|
||||
"kms:ListKeys", // if you need to specify the KMS key
|
||||
"kms:ListAliases", // if you need to specify the KMS key
|
||||
"kms:Encrypt", // if you need to specify the KMS key
|
||||
"kms:Decrypt" // if you need to specify the KMS key
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Step>
|
||||
|
||||
<Step title="Copy the AWS IAM Role ARN">
|
||||

|
||||
</Step>
|
||||
|
||||
<Step title="Setup AWS Connection in Infisical">
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
1. Navigate to the App Connections tab on the Organization Settings page.
|
||||

|
||||
|
||||
2. Select the **AWS Connection** option.
|
||||

|
||||
|
||||
3. Select the **Assume Role** method option and provide the **AWS IAM Role ARN** obtained from the previous step and press **Connect to AWS**.
|
||||

|
||||
|
||||
4. Your **AWS Connection** is now available for use.
|
||||

|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
To create an AWS Connection, make an API request to the [Create AWS
|
||||
Connection](/api-reference/endpoints/app-connections/aws/create) API endpoint.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --request POST \
|
||||
--url https://app.infisical.com/api/v1/app-connections/aws \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
"name": "my-aws-connection",
|
||||
"method": "assume-role",
|
||||
"credentials": {
|
||||
"roleArn": "...",
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"appConnection": {
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"name": "my-aws-connection",
|
||||
"version": 123,
|
||||
"orgId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"createdAt": "2023-11-07T05:31:56Z",
|
||||
"updatedAt": "2023-11-07T05:31:56Z",
|
||||
"app": "aws",
|
||||
"method": "assume-role",
|
||||
"credentials": {}
|
||||
}
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
</Tab>
|
||||
<Tab title="Access Key">
|
||||
Infisical will use the provided **Access Key ID** and **Secret Key** to connect to your AWS instance.
|
||||
|
||||
**Prerequisites:**
|
||||
|
||||
- Set up and add envars to [Infisical Cloud](https://app.infisical.com)
|
||||
|
||||
<Steps>
|
||||
<Step title="Create the Managing User IAM Role for Infisical">
|
||||
1. Navigate to the [Create IAM Role](https://console.aws.amazon.com/iamv2/home#/roles/create?step=selectEntities) page in your AWS Console.
|
||||

|
||||
|
||||
2. Select **AWS Account** as the **Trusted Entity Type**.
|
||||
3. Choose **Another AWS Account** and enter **381492033652** (Infisical AWS Account ID). This restricts the role to be assumed only by Infisical. If self-hosting, provide your AWS account number instead.
|
||||
4. Optionally, enable **Require external ID** and enter your **Organization ID** to further enhance security.
|
||||
</Step>
|
||||
|
||||
<Step title="Add Required Permissions for the IAM Role">
|
||||
Depending on your use case, add one or more of the following policies to your IAM Role:
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Secrets Sync">
|
||||
<AccordionGroup>
|
||||
<Accordion title="AWS Secrets Manager">
|
||||
Use the following custom policy to grant the minimum permissions required by Infisical to sync secrets to AWS Secrets Manager:
|
||||
|
||||

|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AllowSecretsManagerAccess",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"secretsmanager:GetSecretValue",
|
||||
"secretsmanager:CreateSecret",
|
||||
"secretsmanager:UpdateSecret",
|
||||
"secretsmanager:DescribeSecret",
|
||||
"secretsmanager:TagResource",
|
||||
"secretsmanager:UntagResource",
|
||||
"kms:ListKeys",
|
||||
"kms:ListAliases",
|
||||
"kms:Encrypt",
|
||||
"kms:Decrypt"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
</Accordion>
|
||||
<Accordion title="AWS Parameter Store">
|
||||
Use the following custom policy to grant the minimum permissions required by Infisical to sync secrets to AWS Parameter Store:
|
||||
|
||||

|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AllowSSMAccess",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ssm:PutParameter",
|
||||
"ssm:DeleteParameter",
|
||||
"ssm:GetParameters",
|
||||
"ssm:GetParametersByPath",
|
||||
"ssm:DescribeParameters",
|
||||
"ssm:DeleteParameters",
|
||||
"ssm:AddTagsToResource", // if you need to add tags to secrets
|
||||
"kms:ListKeys", // if you need to specify the KMS key
|
||||
"kms:ListAliases", // if you need to specify the KMS key
|
||||
"kms:Encrypt", // if you need to specify the KMS key
|
||||
"kms:Decrypt" // if you need to specify the KMS key
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Step>
|
||||
<Step title="Obtain Access Key ID and Secret Access Key">
|
||||
Retrieve an AWS **Access Key ID** and a **Secret Key** for your IAM user in **IAM > Users > User > Security credentials > Access keys**.
|
||||
|
||||

|
||||

|
||||

|
||||
</Step>
|
||||
<Step title="Setup AWS Connection in Infisical">
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
1. Navigate to the App Connections tab on the Organization Settings page.
|
||||

|
||||
|
||||
2. Select the **AWS Connection** option.
|
||||

|
||||
|
||||
3. Select the **Access Key** method option and provide the **Access Key ID** and **Secret Key** obtained from the previous step and press **Connect to AWS**.
|
||||

|
||||
|
||||
4. Your **AWS Connection** is now available for use.
|
||||

|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
To create an AWS Connection, make an API request to the [Create AWS
|
||||
Connection](/api-reference/endpoints/app-connections/aws/create) API endpoint.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --request POST \
|
||||
--url https://app.infisical.com/api/v1/app-connections/aws \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
"name": "my-aws-connection",
|
||||
"method": "access-key",
|
||||
"credentials": {
|
||||
"accessKeyId": "...",
|
||||
"secretKey": "..."
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"appConnection": {
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"name": "my-aws-connection",
|
||||
"version": 123,
|
||||
"orgId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"createdAt": "2023-11-07T05:31:56Z",
|
||||
"updatedAt": "2023-11-07T05:31:56Z",
|
||||
"app": "aws",
|
||||
"method": "access-key",
|
||||
"credentials": {
|
||||
"accessKeyId": "..."
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
169
docs/integrations/app-connections/github.mdx
Normal file
@@ -0,0 +1,169 @@
|
||||
---
|
||||
title: "GitHub Connection"
|
||||
description: "Learn how to configure a GitHub Connection for Infisical."
|
||||
---
|
||||
|
||||
Infisical supports two methods for connecting to GitHub.
|
||||
|
||||
<Tabs>
|
||||
<Tab title="GitHub App (Recommended)">
|
||||
Infisical will use a GitHub App with finely grained permissions to connect to GitHub.
|
||||
|
||||
**Prerequisites:**
|
||||
|
||||
- Set up and add envars to [Infisical Cloud](https://app.infisical.com)
|
||||
|
||||
<Accordion title="Self-Hosted Instance">
|
||||
Using the GitHub integration with app authentication on a self-hosted instance of Infisical requires configuring an application on GitHub
|
||||
and registering your instance with it.
|
||||
|
||||
<Steps>
|
||||
<Step title="Create an application on GitHub">
|
||||
Navigate to the GitHub app settings [here](https://github.com/settings/apps). Click **New GitHub App**.
|
||||
|
||||

|
||||
|
||||
Give the application a name, a homepage URL (your self-hosted domain i.e. `https://your-domain.com`), and a callback URL (i.e. `https://your-domain.com/app-connections/github/oauth/callback`).
|
||||
|
||||

|
||||
|
||||
Enable request user authorization during app installation.
|
||||

|
||||
|
||||
Disable webhook by unchecking the Active checkbox.
|
||||

|
||||
|
||||
Set the repository permissions as follows: Metadata: Read-only, Secrets: Read and write, Environments: Read and write, Actions: Read.
|
||||

|
||||
|
||||
Similarly, set the organization permissions as follows: Secrets: Read and write.
|
||||

|
||||
|
||||
Create the Github application.
|
||||

|
||||
|
||||
<Note>
|
||||
If you have a GitHub organization, you can create an application under it
|
||||
in your organization Settings > Developer settings > GitHub Apps > New GitHub App.
|
||||
</Note>
|
||||
</Step>
|
||||
<Step title="Add your application credentials to Infisical">
|
||||
Generate a new **Client Secret** for your GitHub application.
|
||||

|
||||
|
||||
Generate a new **Private Key** for your Github application.
|
||||

|
||||
|
||||
Obtain the necessary Github application credentials. This would be the application slug, client ID, app ID, client secret, and private key.
|
||||

|
||||
|
||||
Back in your Infisical instance, add the five new environment variables for the credentials of your GitHub application:
|
||||
|
||||
- `INF_APP_CONNECTION_GITHUB_APP_CLIENT_ID`: The **Client ID** of your GitHub application.
|
||||
- `INF_APP_CONNECTION_GITHUB_APP_CLIENT_SECRET`: The **Client Secret** of your GitHub application.
|
||||
- `INF_APP_CONNECTION_GITHUB_APP_CLIENT_SLUG`: The **Slug** of your GitHub application. This is the one found in the URL.
|
||||
- `INF_APP_CONNECTION_GITHUB_APP_CLIENT_APP_ID`: The **App ID** of your GitHub application.
|
||||
- `INF_APP_CONNECTION_GITHUB_APP_CLIENT_PRIVATE_KEY`: The **Private Key** of your GitHub application.
|
||||
|
||||
Once added, restart your Infisical instance and use the GitHub integration via app authentication.
|
||||
</Step>
|
||||
</Steps>
|
||||
</Accordion>
|
||||
|
||||
## Setup GitHub Connection in Infisical
|
||||
|
||||
<Steps>
|
||||
<Step title="Navigate to the App Connections">
|
||||
Navigate to the **App Connections** tab on the **Organization Settings** page.
|
||||

|
||||
</Step>
|
||||
<Step title="Add Connection">
|
||||
Select the **GitHub Connection** option from the connection options modal.
|
||||

|
||||
</Step>
|
||||
<Step title="Authorize Connection">
|
||||
Select the **GitHub App** method and click **Connect to GitHub**.
|
||||

|
||||
</Step>
|
||||
<Step title="Install GitHub App">
|
||||
You will then be redirected to the GitHub app installation page.
|
||||
|
||||
Install and authorize the GitHub application. This will redirect you back to Infisical's App Connections page.
|
||||

|
||||
</Step>
|
||||
<Step title="Connection Created">
|
||||
Your **GitHub Connection** is now available for use.
|
||||

|
||||
</Step>
|
||||
</Steps>
|
||||
</Tab>
|
||||
<Tab title="OAuth">
|
||||
Infisical will use an OAuth App to connect to GitHub.
|
||||
|
||||
**Prerequisites:**
|
||||
|
||||
- Set up and add envars to [Infisical Cloud](https://app.infisical.com)
|
||||
|
||||
<Accordion title="Self-Hosted Instance">
|
||||
Using the GitHub integration on a self-hosted instance of Infisical requires configuring an OAuth application in GitHub
|
||||
and registering your instance with it.
|
||||
<Steps>
|
||||
<Step title="Create an OAuth application in GitHub">
|
||||
Navigate to your user Settings > Developer settings > OAuth Apps to create a new GitHub OAuth application.
|
||||
|
||||

|
||||

|
||||

|
||||
|
||||
Create the OAuth application. As part of the form, set the **Homepage URL** to your self-hosted domain `https://your-domain.com`
|
||||
and the **Authorization callback URL** to `https://your-domain.com/app-connections/github/oauth/callback`.
|
||||
|
||||

|
||||
|
||||
<Note>
|
||||
If you have a GitHub organization, you can create an OAuth application under it
|
||||
in your organization Settings > Developer settings > OAuth Apps > New Org OAuth App.
|
||||
</Note>
|
||||
</Step>
|
||||
<Step title="Add your OAuth application credentials to Infisical">
|
||||
Obtain the **Client ID** and generate a new **Client Secret** for your GitHub OAuth application.
|
||||
|
||||

|
||||
|
||||
Back in your Infisical instance, add two new environment variables for the credentials of your GitHub OAuth application:
|
||||
|
||||
- `INF_APP_CONNECTION_GITHUB_OAUTH_CLIENT_ID`: The **Client ID** of your GitHub OAuth application.
|
||||
- `INF_APP_CONNECTION_GITHUB_OAUTH_CLIENT_SECRET`: The **Client Secret** of your GitHub OAuth application.
|
||||
|
||||
Once added, restart your Infisical instance and use the GitHub integration.
|
||||
</Step>
|
||||
</Steps>
|
||||
</Accordion>
|
||||
|
||||
## Setup GitHub Connection in Infisical
|
||||
|
||||
<Steps>
|
||||
<Step title="Navigate to the App Connections">
|
||||
Navigate to the **App Connections** tab on the **Organization Settings** page.
|
||||

|
||||
</Step>
|
||||
<Step title="Add Connection">
|
||||
Select the **GitHub Connection** option from the connection options modal.
|
||||

|
||||
</Step>
|
||||
<Step title="Authorize Connection">
|
||||
Select the **OAuth** method and click **Connect to GitHub**.
|
||||

|
||||
</Step>
|
||||
<Step title="Grant Access">
|
||||
You will then be redirected to the GitHub to grant Infisical access to your GitHub account (organization and repo privileges).
|
||||
Once granted, you will redirect you back to Infisical's App Connections page.
|
||||

|
||||
</Step>
|
||||
<Step title="Connection Created">
|
||||
Your **GitHub Connection** is now available for use.
|
||||

|
||||
</Step>
|
||||
</Steps>
|
||||
</Tab>
|
||||
</Tabs>
|
||||
77
docs/integrations/app-connections/overview.mdx
Normal file
@@ -0,0 +1,77 @@
|
||||
---
|
||||
sidebarTitle: "Overview"
|
||||
description: "Learn how to manage and configure third-party app connections with Infisical."
|
||||
---
|
||||
|
||||
App Connections enable your organization to integrate Infisical with third-party services in a secure and versatile way.
|
||||
|
||||
## Concept
|
||||
|
||||
App Connections are an organization-level resource used to establish connections with third-party applications
|
||||
that can be used across Infisical projects. Example use cases include syncing secrets, generating dynamic secrets, and more.
|
||||
|
||||
<br />
|
||||
|
||||
<div align="center">
|
||||
|
||||
```mermaid
|
||||
%%{init: {'flowchart': {'curve': 'linear'} } }%%
|
||||
graph TD
|
||||
A[AWS]
|
||||
B[AWS Connection]
|
||||
C[Project 1 Secret Sync]
|
||||
D[Project 2 Secret Sync]
|
||||
E[Project 3 Generate Dynamic Secret]
|
||||
|
||||
B --> A
|
||||
C --> B
|
||||
D --> B
|
||||
E --> B
|
||||
|
||||
classDef default fill:#ffffff,stroke:#666,stroke-width:2px,rx:10px,color:black
|
||||
classDef aws fill:#FFF2B2,stroke:#E6C34A,stroke-width:2px,color:black,rx:15px
|
||||
classDef project fill:#E6F4FF,stroke:#0096D6,stroke-width:2px,color:black,rx:15px
|
||||
classDef connection fill:#F4FFE6,stroke:#96D600,stroke-width:2px,color:black,rx:15px
|
||||
|
||||
class A aws
|
||||
class B connection
|
||||
class C,D,E project
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
## Workflow
|
||||
|
||||
App Connections require initial setup in both your third-party application and Infisical. Follow these steps to establish a secure connection:
|
||||
|
||||
<Note>
|
||||
For step-by-step guides specific to each application, refer to the App Connections section in the Navigation Bar.
|
||||
</Note>
|
||||
|
||||
1. <strong>Create Access Entity:</strong> If necessary, create an entity such as a service account or role within the third-party application you want to connect to. Be sure
|
||||
to limit the access of this entity to the minimal permission set required to perform the operations you need. For example:
|
||||
- For secret syncing: Read/write permissions to specific secret stores
|
||||
- For dynamic secrets: Permissions to create temporary credentials
|
||||
|
||||
<Tip>
|
||||
Whenever possible, Infisical encourages creating a designated service account for your App Connection to limit the scope of permissions based on your use-case.
|
||||
</Tip>
|
||||
|
||||
2. <strong>Generate Authentication Credentials:</strong> Obtain the required credentials from your third-party application. These can vary between applications and might be:
|
||||
- an API key or access token
|
||||
- A client ID and secret pair
|
||||
- other credentials, etc.
|
||||
|
||||
3. <strong>Create App Connection:</strong> Configure the connection in Infisical using your generated credentials through either the UI or API.
|
||||
|
||||
<Info>
|
||||
Some App Connections can only be created via the UI such as connections using OAuth.
|
||||
</Info>
|
||||
|
||||
4. <strong>Utilize the Connection:</strong> Use your App Connection for various features across Infisical such as our Secrets Sync by selecting it via the dropdown menu
|
||||
in the UI or by passing the associated `connectionId` when generating resources via the API.
|
||||
|
||||
<Note>
|
||||
Infisical is continuously expanding its third-party application support. If your desired application isn't listed,
|
||||
you can still use previous methods of connecting to it such as our Native Integrations.
|
||||
</Note>
|
||||
@@ -11,21 +11,30 @@ Prerequisites:
|
||||
<Step title="Authorize Infisical for CircleCI">
|
||||
Obtain an API token in User Settings > Personal API Tokens
|
||||
|
||||

|
||||

|
||||
|
||||
Navigate to your project's integrations tab in Infisical.
|
||||
|
||||

|
||||

|
||||
|
||||
Press on the CircleCI tile and input your CircleCI API token to grant Infisical access to your CircleCI account.
|
||||
|
||||

|
||||

|
||||
|
||||
</Step>
|
||||
<Step title="Start integration">
|
||||
Select which Infisical environment secrets you want to sync to which CircleCI project and press create integration to start syncing secrets to CircleCI.
|
||||
Select which Infisical environment secrets you want to sync to which CircleCI project or context.
|
||||
<Tabs>
|
||||
<Tab title="Project">
|
||||

|
||||
</Tab>
|
||||
<Tab title="Context">
|
||||

|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
Finally, press create integration to start syncing secrets to CircleCI.
|
||||

|
||||
|
||||

|
||||

|
||||
</Step>
|
||||
</Steps>
|
||||
</Steps>
|
||||
|
||||
@@ -29,6 +29,36 @@ description: "How to sync secrets from Infisical to Azure App Configuration"
|
||||

|
||||
|
||||
Press create integration to start syncing secrets to Azure App Configuration.
|
||||
|
||||
<Note>
|
||||
The Azure App Configuration integration requires the following permissions to be set on the user / service principal
|
||||
for Infisical to sync secrets to Azure App Configuration: `Read Key-Value`, `Write Key-Value`, `Delete Key-Value`.
|
||||
|
||||
Any role with these permissions would work such as the **App Configuration Data Owner** role. Alternatively, you can use the
|
||||
**App Configuration Data Reader** role for read-only access or **App Configuration Data Contributor** role for read/write access.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
<Step title="Additional Configuration">
|
||||
|
||||
#### Azure references
|
||||
When adding secrets in Infisical that reference Azure Key Vault secrets, Infisical will automatically sets the content type to `application/vnd.microsoft.appconfig.keyvaultref+json;charset=utf-8` in Azure App Configuration.
|
||||
The following reference formats are automatically detected when added on Infisical's side:
|
||||
- `{ "uri": "https://my-key-vault.vault.azure.net/secrets/my-secret" }`
|
||||
- `https://my-key-vault.vault.azure.net/secrets/my-secret`
|
||||
|
||||
#### Azure Labels
|
||||
You can sync secrets from Infisical to Azure with custom labels by enabling the `Use Labels` option during setup:
|
||||
|
||||
**When enabled**: Secrets will be pushed to Azure with your specified label
|
||||
|
||||
**When disabled**: Secrets will be pushed with an empty (null) label
|
||||
|
||||
<Info>
|
||||
If you have set the initial sync to `import` have behavior, the label selection affects which secrets are imported from Azure:
|
||||
- With `Use Labels` disabled: Only secrets with empty labels are imported on initial sync
|
||||
- With `Use Labels` enabled: Only secrets matching your specified label are imported on initial sync
|
||||
</Info>
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ You'll need to create a new personal access token (PAT) in order to authenticate
|
||||

|
||||
|
||||
<Note>
|
||||
Please make sure that the token has access to the following scopes: Variable Groups _(read/write)_, Release _(read/write)_, Project and Team _(read)_, Service Connections _(read & query)_
|
||||
Please make sure that the token has access to the following scopes: Variable Groups _(read, create, & manage)_, Release _(read/write)_, Project and Team _(read)_, Service Connections _(read & query)_
|
||||
</Note>
|
||||
</Step>
|
||||
<Step title="Copy the new access token">
|
||||
|
||||
@@ -17,6 +17,10 @@ description: "How to sync secrets from Infisical to Azure Key Vault"
|
||||

|
||||
|
||||
Press on the Azure Key Vault tile and grant Infisical access to Azure Key Vault.
|
||||
You can optionally authenticate against a specific tenant by providing the Azure tenant or directory ID.
|
||||
|
||||

|
||||
|
||||
</Step>
|
||||
<Step title="Start integration">
|
||||
Obtain the Vault URI of your key vault in the Overview tab.
|
||||
|
||||
@@ -41,10 +41,54 @@ The operator can be install via [Helm](https://helm.sh) or [kubectl](https://git
|
||||
helm install --generate-name infisical-helm-charts/secrets-operator --version=0.1.4 --set controllerManager.manager.image.tag=v0.2.0
|
||||
```
|
||||
|
||||
**Namespace-scoped Installation**
|
||||
|
||||
The operator can be configured to watch and manage secrets in a specific namespace instead of having cluster-wide access. This is useful for:
|
||||
|
||||
- **Enhanced Security**: Limit the operator's permissions to only specific namespaces instead of cluster-wide access
|
||||
- **Multi-tenant Clusters**: Run separate operator instances for different teams or applications
|
||||
- **Resource Isolation**: Ensure operators in different namespaces don't interfere with each other
|
||||
- **Development & Testing**: Run development and production operators side by side in isolated namespaces
|
||||
|
||||
**Note**: For multiple namespace-scoped installations, only the first installation should install CRDs. Subsequent installations should set `installCRDs: false` to avoid conflicts.
|
||||
|
||||
```bash
|
||||
# First namespace installation (with CRDs)
|
||||
helm install operator-namespace1 infisical-helm-charts/secrets-operator \
|
||||
--namespace first-namespace \
|
||||
--set scopedNamespace=first-namespace \
|
||||
--set scopedRBAC=true
|
||||
|
||||
# Subsequent namespace installations
|
||||
helm install operator-namespace2 infisical-helm-charts/secrets-operator \
|
||||
--namespace another-namespace \
|
||||
--set scopedNamespace=another-namespace \
|
||||
--set scopedRBAC=true \
|
||||
--set installCRDs=false
|
||||
```
|
||||
|
||||
When scoped to a namespace, the operator will:
|
||||
|
||||
- Only watch InfisicalSecrets in the specified namespace
|
||||
- Only create/update Kubernetes secrets in that namespace
|
||||
- Only access deployments in that namespace
|
||||
|
||||
The default configuration gives cluster-wide access:
|
||||
|
||||
```yaml
|
||||
installCRDs: true # Install CRDs (set to false for additional namespace installations)
|
||||
scopedNamespace: "" # Empty for cluster-wide access
|
||||
scopedRBAC: false # Cluster-wide permissions
|
||||
```
|
||||
|
||||
If you want to install operators in multiple namespaces simultaneously:
|
||||
- Make sure to set `installCRDs: false` for all but one of the installations to avoid conflicts, as CRDs are cluster-wide resources.
|
||||
- Use unique release names for each installation (e.g., operator-namespace1, operator-namespace2).
|
||||
|
||||
</Tab>
|
||||
<Tab title="Kubectl">
|
||||
For production deployments, it is highly recommended to set the version of the Kubernetes operator manually instead of pointing to the latest version.
|
||||
Doing so will help you avoid accidental updates to the newest release which may introduce unintended breaking changes. View all application versions [here](https://hub.docker.com/r/infisical/kubernetes-operator/tags).
|
||||
<Tab title="Kubectl">
|
||||
For production deployments, it is highly recommended to set the version of the Kubernetes operator manually instead of pointing to the latest version.
|
||||
Doing so will help you avoid accidental updates to the newest release which may introduce unintended breaking changes. View all application versions [here](https://hub.docker.com/r/infisical/kubernetes-operator/tags).
|
||||
|
||||
The command below will install the most recent version of the Kubernetes operator.
|
||||
However, to set the version manually, download the manifest and set the image tag version of `infisical/kubernetes-operator` according to your desired version.
|
||||
@@ -700,6 +744,7 @@ 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"`
|
||||
@@ -708,6 +753,7 @@ type TemplateSecret struct {
|
||||
```
|
||||
|
||||
#### Example template configuration:
|
||||
|
||||
```golang
|
||||
managedSecretReference:
|
||||
secretName: managed-secret
|
||||
@@ -719,19 +765,23 @@ type TemplateSecret struct {
|
||||
```
|
||||
|
||||
When you run the following command:
|
||||
|
||||
```bash
|
||||
kubectl get secret managed-secret -o jsonpath='{.data}'
|
||||
```
|
||||
|
||||
You'll receive Kubernetes secrets output that includes the NEW_KEY:
|
||||
|
||||
```bash
|
||||
{... "KEY":"d29ybGQ=","NEW_KEY":"LyBoZWxsbw=="}
|
||||
```
|
||||
|
||||
When you set `includeAllSecrets` as `false` the Kubernetes secrets outputs will be:
|
||||
|
||||
```bash
|
||||
{"NEW_KEY":"LyBoZWxsbw=="}
|
||||
```
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="managedSecretReference.creationPolicy">
|
||||
Creation polices allow you to control whether or not owner references should be added to the managed Kubernetes secret that is generated by the Infisical operator.
|
||||
|
||||
@@ -32,10 +32,7 @@
|
||||
"thumbsRating": true
|
||||
},
|
||||
"api": {
|
||||
"baseUrl": [
|
||||
"https://app.infisical.com",
|
||||
"http://localhost:8080"
|
||||
]
|
||||
"baseUrl": ["https://app.infisical.com", "http://localhost:8080"]
|
||||
},
|
||||
"topbarLinks": [
|
||||
{
|
||||
@@ -76,9 +73,7 @@
|
||||
"documentation/getting-started/introduction",
|
||||
{
|
||||
"group": "Quickstart",
|
||||
"pages": [
|
||||
"documentation/guides/local-development"
|
||||
]
|
||||
"pages": ["documentation/guides/local-development"]
|
||||
},
|
||||
{
|
||||
"group": "Guides",
|
||||
@@ -119,6 +114,7 @@
|
||||
"documentation/platform/pki/alerting"
|
||||
]
|
||||
},
|
||||
"documentation/platform/ssh",
|
||||
{
|
||||
"group": "Key Management (KMS)",
|
||||
"pages": [
|
||||
@@ -229,6 +225,7 @@
|
||||
"documentation/platform/identities/gcp-auth",
|
||||
"documentation/platform/identities/azure-auth",
|
||||
"documentation/platform/identities/aws-auth",
|
||||
"documentation/platform/identities/jwt-auth",
|
||||
{
|
||||
"group": "OIDC Auth",
|
||||
"pages": [
|
||||
@@ -323,6 +320,7 @@
|
||||
"cli/commands/run",
|
||||
"cli/commands/secrets",
|
||||
"cli/commands/dynamic-secrets",
|
||||
"cli/commands/ssh",
|
||||
"cli/commands/export",
|
||||
"cli/commands/token",
|
||||
"cli/commands/service-token",
|
||||
@@ -467,15 +465,11 @@
|
||||
},
|
||||
{
|
||||
"group": "Build Tool Integrations",
|
||||
"pages": [
|
||||
"integrations/build-tools/gradle"
|
||||
]
|
||||
"pages": ["integrations/build-tools/gradle"]
|
||||
},
|
||||
{
|
||||
"group": "",
|
||||
"pages": [
|
||||
"sdks/overview"
|
||||
]
|
||||
"pages": ["sdks/overview"]
|
||||
},
|
||||
{
|
||||
"group": "SDK's",
|
||||
@@ -495,9 +489,7 @@
|
||||
"api-reference/overview/authentication",
|
||||
{
|
||||
"group": "Examples",
|
||||
"pages": [
|
||||
"api-reference/overview/examples/integration"
|
||||
]
|
||||
"pages": ["api-reference/overview/examples/integration"]
|
||||
}
|
||||
]
|
||||
},
|
||||
@@ -593,6 +585,16 @@
|
||||
"api-reference/endpoints/oidc-auth/revoke"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "JWT Auth",
|
||||
"pages": [
|
||||
"api-reference/endpoints/jwt-auth/login",
|
||||
"api-reference/endpoints/jwt-auth/attach",
|
||||
"api-reference/endpoints/jwt-auth/retrieve",
|
||||
"api-reference/endpoints/jwt-auth/update",
|
||||
"api-reference/endpoints/jwt-auth/revoke"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Groups",
|
||||
"pages": [
|
||||
@@ -772,15 +774,11 @@
|
||||
},
|
||||
{
|
||||
"group": "Service Tokens",
|
||||
"pages": [
|
||||
"api-reference/endpoints/service-tokens/get"
|
||||
]
|
||||
"pages": ["api-reference/endpoints/service-tokens/get"]
|
||||
},
|
||||
{
|
||||
"group": "Audit Logs",
|
||||
"pages": [
|
||||
"api-reference/endpoints/audit-logs/export-audit-log"
|
||||
]
|
||||
"pages": ["api-reference/endpoints/audit-logs/export-audit-log"]
|
||||
}
|
||||
]
|
||||
},
|
||||
@@ -850,6 +848,40 @@
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Infisical SSH",
|
||||
"pages": [
|
||||
{
|
||||
"group": "Certificates",
|
||||
"pages": [
|
||||
"api-reference/endpoints/ssh/certificates/issue-credentials",
|
||||
"api-reference/endpoints/ssh/certificates/sign-key"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Certificate Authorities",
|
||||
"pages": [
|
||||
"api-reference/endpoints/ssh/ca/list",
|
||||
"api-reference/endpoints/ssh/ca/create",
|
||||
"api-reference/endpoints/ssh/ca/read",
|
||||
"api-reference/endpoints/ssh/ca/update",
|
||||
"api-reference/endpoints/ssh/ca/delete",
|
||||
"api-reference/endpoints/ssh/ca/public-key",
|
||||
"api-reference/endpoints/ssh/ca/list-certificate-templates"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Certificate Templates",
|
||||
"pages": [
|
||||
"api-reference/endpoints/ssh/certificate-templates/list",
|
||||
"api-reference/endpoints/ssh/certificate-templates/create",
|
||||
"api-reference/endpoints/ssh/certificate-templates/read",
|
||||
"api-reference/endpoints/ssh/certificate-templates/update",
|
||||
"api-reference/endpoints/ssh/certificate-templates/delete"
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Infisical KMS",
|
||||
"pages": [
|
||||
@@ -879,9 +911,7 @@
|
||||
},
|
||||
{
|
||||
"group": "",
|
||||
"pages": [
|
||||
"changelog/overview"
|
||||
]
|
||||
"pages": ["changelog/overview"]
|
||||
},
|
||||
{
|
||||
"group": "Contributing",
|
||||
@@ -905,16 +935,11 @@
|
||||
},
|
||||
{
|
||||
"group": "Contributing to SDK",
|
||||
"pages": [
|
||||
"contributing/sdk/developing"
|
||||
]
|
||||
"pages": ["contributing/sdk/developing"]
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"integrations": {
|
||||
"intercom": "hsg644ru"
|
||||
},
|
||||
"analytics": {
|
||||
"koala": {
|
||||
"publicApiKey": "pk_b50d7184e0e39ddd5cdb43cf6abeadd9b97d"
|
||||
@@ -1090,4 +1115,4 @@
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -418,7 +418,53 @@ When set, all visits to the Infisical login page will automatically redirect use
|
||||
information.
|
||||
</Accordion>
|
||||
|
||||
## Native secret integrations
|
||||
## App Connections
|
||||
|
||||
You can configure third-party app connections for re-use across Infisical Projects.
|
||||
|
||||
<Accordion title="AWS Assume Role Connection">
|
||||
<ParamField query="INF_APP_CONNECTION_AWS_ACCESS_KEY_ID" type="string" default="none" optional>
|
||||
The AWS IAM User access key ID for assuming roles
|
||||
</ParamField>
|
||||
|
||||
<ParamField query="INF_APP_CONNECTION_AWS_SECRET_ACCESS_KEY" type="string" default="none" optional>
|
||||
The AWS IAM User secret key for assuming roles
|
||||
</ParamField>
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="GitHub App Connection">
|
||||
<ParamField query="INF_APP_CONNECTION_GITHUB_APP_ID" type="string" default="none" optional>
|
||||
The ID of the GitHub App
|
||||
</ParamField>
|
||||
|
||||
<ParamField query="INF_APP_CONNECTION_GITHUB_APP_SLUG" type="string" default="none" optional>
|
||||
The slug of the GitHub App
|
||||
</ParamField>
|
||||
|
||||
<ParamField query="INF_APP_CONNECTION_GITHUB_APP_CLIENT_ID" type="string" default="none" optional>
|
||||
The client ID for the GitHub App
|
||||
</ParamField>
|
||||
|
||||
<ParamField query="INF_APP_CONNECTION_GITHUB_APP_CLIENT_SECRET" type="string" default="none" optional>
|
||||
The client secret for the GitHub App
|
||||
</ParamField>
|
||||
|
||||
<ParamField query="INF_APP_CONNECTION_GITHUB_APP_PRIVATE_KEY" type="string" default="none" optional>
|
||||
The private key for the GitHub App
|
||||
</ParamField>
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="GitHub OAuth Connection">
|
||||
<ParamField query="INF_APP_CONNECTION_GITHUB_OAUTH_CLIENT_ID" type="string" default="none" optional>
|
||||
The OAuth2 client ID for GitHub OAuth Connection
|
||||
</ParamField>
|
||||
|
||||
<ParamField query="INF_APP_CONNECTION_GITHUB_OAUTH_CLIENT_SECRET" type="string" default="none" optional>
|
||||
The OAuth2 client secret for GitHub OAuth Connection
|
||||
</ParamField>
|
||||
</Accordion>
|
||||
|
||||
## Native Secret Integrations
|
||||
|
||||
To help you sync secrets from Infisical to services such as Github and Gitlab, Infisical provides native integrations out of the box.
|
||||
|
||||
@@ -492,7 +538,7 @@ To help you sync secrets from Infisical to services such as Github and Gitlab, I
|
||||
</ParamField>
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="AWS">
|
||||
<Accordion title="AWS Integration">
|
||||
<ParamField query="CLIENT_ID_AWS_INTEGRATION" type="string" default="none" optional>
|
||||
The AWS IAM User access key for assuming roles.
|
||||
</ParamField>
|
||||
|
||||