kviklet v0.8.0
类似 Pull Request 的数据库查询审批/批准流程，用于合规但顺畅的工程人员访问生产环境。
Kviklet
Kviklet.dev | 发布说明 | Discord
安全访问生产环境，同时不损害开发者生产力。
Kviklet（发音为 Quick-let）遵循四眼原则并具有高度可配置性，允许对单个 SQL 语句或数据库会话实现类似拉取请求的审查与批准流程。这使得工程团队能够自行管理谁在何时可以访问哪些数据，从而使组织在保持安全和合规的同时，拥抱现代化的、赋能的、真正“DevOps”的工作流程。
Kviklet 是一个自托管的 Docker 容器，为您提供一个单页 Web 应用。登录后即可创建 SQL 请求或批准他人的请求。可选的企业版许可证解锁高级功能，如 SAML 认证、基于角色的审查要求、角色同步和 API 密钥。您可以在 kviklet.dev 申请企业版许可证。
我们目前支持 Postgres、MySQL、MS SQL Server 和 MongoDB。
功能特性
Kviklet 提供了工程团队以简单但安全的方式管理其生产数据库访问所需的多种功能：
- SSO（OIDC、Google、Keycloak 等）：无需用户名或密码即可登录 Kviklet。不再需要共享数据库凭据。
- LDAP 支持：使用您的 LDAP 凭据登录 Kviklet。
- SAML 支持：使用您的 SAML 凭据登录 Kviklet。（仅限企业版）
- 审查/批准流程：对其他开发者的数据请求留下评论和建议。
- 临时访问（1 小时）：在获得批准后，可在一小时内对数据库执行任何语句。
- 单条查询：执行单条语句。允许审查者先审查您的查询再执行。
- 审计日志：单一平面，记录所有已执行语句，包括作者、执行原因等信息。
- RBAC：根据数据库引擎的细粒度限制，配置哪个团队可以访问哪个数据库/表。
- Postgres 代理：启动代理服务器以使用您选择的数据库客户端，但所有操作都将存储在 Kviklet 审计日志中。
- Kubernetes Exec：在您的 Kubernetes 集群中的 Pod 上执行语句。（目前仅支持执行单条命令，暂无实时会话）
- 基于角色的审查门：在执行前需要特定角色的批准。（仅限企业版）
- 角色同步：自动从您的身份提供者组同步用户角色。（仅限企业版）
- API 密钥：以编程方式访问 Kviklet API。（仅限企业版）
按数据库/连接类型划分的功能
大多数功能适用于所有数据库（SSO、LDAP、RBAC、审查/批准流程、审计日志等）。但某些功能受限，原因可能是尚未构建或对该特定用途无意义。下表显示了哪些功能适用于哪些数据库类型：
| 数据库 | 语句审查 | 临时访问 | 代理（Beta） | 执行计划 |
|---|---|---|---|---|
| Postgres | ✓ | ✓ | ✓ | ✓ |
| MySQL | ✓ | ✓ | ✗ | ✓ |
| MariaDB | ✓ | ✓ | ✗ | ✓ |
| SQL Server | ✓ | ✓ | ✗ | ✓ |
| MongoDB | ✓ | ✓ | ✗ | ✗ |
| Kubernetes | ✓ | ✗ | ✗ | ✗ |
安装设置
Kviklet 作为简单的 Docker 容器提供。
您可以在 Releases 找到可用版本。我们建议定期更新您使用的版本，因为我们持续构建新功能。
最新的版本是 ghcr.io/kviklet/kviklet:0.7.0，您也可以使用 :main，但有时我们可能意外合并了有问题的代码。不过我们会尽量避免这种情况。
快速开始
如果您只是想试用一下：
-
这是一个最小的 docker-compose.yaml：
点击展开 compose 内容
``` services: postgres: image: postgres:16 restart: always environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: postgres POSTGRES_DB: postgres ports: - "5432:5432" volumes: - ./postgres-data:/var/lib/postgresql/data # - ./sample_data.sql:/docker-entrypoint-initdb.d/init.sqlkviklet-postgres: image: postgres:16 restart: always environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: postgres POSTGRES_DB: kviklet ports: - "5433:5432" volumes: - ./kviklet-postgres-data:/var/lib/postgresql/data
kviklet: image: ghcr.io/kviklet/kviklet:main ports: - "80:8080" environment: - SPRING_DATASOURCE_URL=jdbc:postgresql://kviklet-postgres:5432/kviklet - SPRING_DATASOURCE_USERNAME=postgres - SPRING_DATASOURCE_PASSWORD=postgres - INITIAL_USER_EMAIL=[email protected] - INITIAL_USER_PASSWORD=admin depends_on: - kviklet-postgres
-
通过
docker-compose up -d运行docker-compose.yml。Kviklet 将在端口80上启动，访问localhost进行体验。管理员登录信息为 [email protected]，密码为admin。 -
docker-compose 包含一个额外的 PostgreSQL 数据库，你可以在 Kviklet 中设置连接。为了使该数据库包含一些数据，请取消注释以下行： ``` - ./sample_data.sql:/docker-entrypoint-initdb.d/init.sql
并创建一个 sample_data.sql 文件：
点击展开 sample_data.sql 内容
```sql CREATE TABLE Locations ( Name VARCHAR(100) NOT NULL, Address VARCHAR(255) NOT NULL, City VARCHAR(100) NOT NULL, Country VARCHAR(100) NOT NULL, PostalCode VARCHAR(20) NOT NULL );alter table public.Locations owner to postgres;
INSERT INTO public.Locations (Name, Address, City, Country, PostalCode) VALUES ('Central Park', '59th to 110th St', 'New York', 'USA', '10022'), ('Eiffel Tower', 'Champ de Mars, 5 Avenue Anatole', 'Paris', 'France', '75007'), ('Colosseum', 'Piazza del Colosseo, 1', 'Rome', 'Italy', '00184'), ('Sydney Opera House', 'Bennelong Point', 'Sydney', 'Australia', '2000'), ('Great Wall of China', 'Huairou District', 'Beijing', 'China', '101405');
</details>
### 数据库设置
Kviklet 需要自己的 postgres 数据库（或至少一个模式）来保存关于查询、连接、审批等的元数据。
你可以在这里找到他们的官方镜像：https://hub.docker.com/_/postgres，或者使用你选择的云提供商提供的托管版本。
启动 kviklet 容器时，你需要相应地设置以下三个环境变量：```
SPRING_DATASOURCE_PASSWORD = password
SPRING_DATASOURCE_USERNAME = username
SPRING_DATASOURCE_URL = jdbc:postgresql://[host]:[port]/[database]?currentSchema=[schema]
替代认证方法
- IAM 认证：
可以使用 AWS IAM 认证进行数据库连接，在这种情况下，您只需省略密码并设置用户名。
您还需要设置环境变量： ```
SPRING_DATASOURCE_IAMAUTH=true
Kviklet 将从常规位置（环境变量、实例角色等）加载凭据，并为连接生成一个令牌。
- 证书： 你也可以使用证书进行数据库连接，示例请参见此处。
初始用户
你需要一个初始管理员用户用于配置。为此设置以下两个环境变量：INITIAL_USER_EMAIL 和 INITIAL_USER_PASSWORD，以便登录 Web 界面。之后可以通过 UI 更改密码。
示例：```
INITIAL_USER_EMAIL=[email protected]
INITIAL_USER_PASSWORD=someverysecurepassword
我们目前将容器发布到GitHub Packages，因此设置好这一切后，你可以运行 `ghcr.io/kviklet/kviklet:main`，不要忘记映射端口 `8080`，这是Kviklet启动时的默认端口。
一个示例的docker run命令如下：```
docker run \
-e SPRING_DATASOURCE_PASSWORD=postgres \
-e SPRING_DATASOURCE_USERNAME=postgres \
-e SPRING_DATASOURCE_URL=jdbc:postgresql://localhost:5432/Kviklet \
-e [email protected] \
-e INITIAL_USER_PASSWORD=someverysecurepassword \
--network host \
ghcr.io/kviklet/kviklet:main
通过 OIDC / OAuth2 的 SSO
如果你希望为你的 Kviklet 实例设置 SSO（这很有意义，否则你必须再次管理密码）。 你需要设置以下 3 个环境变量：``` KVIKLET_IDENTITYPROVIDER_CLIENTID KVIKLET_IDENTITYPROVIDER_CLIENTSECRET KVIKLET_IDENTITYPROVIDER_TYPE=google
The google client id and secret 你只需按照 Google 的说明操作，即可轻松获取：
https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid
对于有效的重定向 URI，你应该配置：https://[kviklet_host]/api/login/oauth2/code/google
对于允许的来源（Allowed Origins），请直接填写你托管的 kviklet URL。
设置这些环境变量后，你组织中的所有成员都可以通过“使用 Google 登录”按钮登录。但默认情况下他们没有权限，你需要在他们首次登录后为其分配角色。
#### Keycloak
如果你想改用 Keycloak 设置单点登录，则需要配置以下 4 个环境变量：```
KVIKLET_IDENTITYPROVIDER_CLIENTID
KVIKLET_IDENTITYPROVIDER_CLIENTSECRET
KVIKLET_IDENTITYPROVIDER_TYPE=keycloak
KVIKLET_IDENTITYPROVIDER_ISSUERURI=http://[host]:[port]/realms/[realm]
当你在 Keycloak 中创建应用程序时，会获得客户端 ID 和密钥。
对于有效的重定向 URI，应配置：https://[kviklet_host]/api/login/oauth2/code/keycloak
对于允许的来源，只需填写你托管的 kviklet URL。
设置这些环境变量后，登录页面应显示一个“使用 Keycloak 登录”按钮，点击后会重定向到你的 Keycloak 实例。在企业版中，你可以启用角色同步功能，自动将角色从 Keycloak 实例同步到 kviklet。更多详情请参见角色同步部分。
GitHub（Beta）
Beta： GitHub 认证是新增功能，尚不支持角色同步——每位新用户默认使用默认角色，需要手动分配角色。
GitHub 不兼容 OIDC（它仅是纯 OAuth 2.0），因此 Kviklet 为其提供了专门支持。设置以下环境变量：``` KVIKLET_IDENTITYPROVIDER_CLIENTID KVIKLET_IDENTITYPROVIDER_CLIENTSECRET KVIKLET_IDENTITYPROVIDER_TYPE=github KVIKLET_IDENTITYPROVIDER_GITHUB_ALLOWEDORGS=your-org,another-org
在 https://github.com/settings/developers 创建一个 GitHub OAuth 应用，并进行如下配置：
- 授权回调 URL：`https://[kviklet_host]/api/login/oauth2/code/github`
- 主页 URL：你托管的 Kviklet URL
`KVIKLET_IDENTITYPROVIDER_GITHUB_ALLOWEDORGS` 是**必需的**（Kviklet 没有它拒绝启动）。GitHub OAuth 应用无法限制谁完成 OAuth 流程，因此 Kviklet 在认证后会调用 `/user/orgs`，并拒绝不属于至少一个允许列表中的组织的用户（不区分大小写，仅检查前 100 个组织）。
为了让组织检查能看到用户的成员资格，用户必须在 OAuth 授权屏幕上，在每个允许列表中的组织旁边点击 **授予**（或 **请求**）。如果该组织启用了“限制第三方 OAuth 应用”，则组织所有者还需要先批准该 OAuth 应用一次，之后任何成员的成员资格才可见。
Kviklet 请求 `read:user`、`user:email` 和 `read:org` 作用域。电子邮件始终从 `/user/emails` 读取，只接受 `primary && verified` 的条目，因此使用私有电子邮件地址的用户也能成功登录。
#### 其他 OIDC 提供商
其他符合 OIDC 标准的提供商（GitLab、Auth0、Okta 等）应该与 Keycloak 的工作方式类似。请注意，`重定向 URI` 会根据你选择的类型而变化，因此如果你选择 `gitlab`，它将是 `https://[kviklet_host]/api/login/oauth2/code/gitlab`。
如果遇到问题，请随时创建 issue，我们目前尚未测试所有 OIDC 提供商，可能存在实现上的细微差异，可能需要更新 Kviklet 端。
### LDAP
Kviklet 支持 LDAP 认证。要启用和配置 LDAP，你可以覆盖以下环境变量：```
LDAP_ENABLED=true
LDAP_URL=ldap://your-ldap-server:389
LDAP_BASE=dc=your,dc=domain,dc=com
LDAP_PRINCIPAL=cn=admin,dc=your,dc=domain,dc=com
LDAP_PASSWORD=your-admin-password
LDAP_UNIQUE_IDENTIFIER_ATTRIBUTE=uid
LDAP_EMAIL_ATTRIBUTE=mail
LDAP_FULL_NAME_ATTRIBUTE=cn
LDAP_USER_OU=people
LDAP_SEARCH_BASE=ou=people
以下是每个设置的含义：
LDAP_ENABLED：设置为true以启用 LDAP 认证。LDAP_URL：LDAP 服务器的 URL。LDAP_BASE：LDAP 搜索的基础 DN。LDAP_PRINCIPAL：用于绑定到 LDAP 服务器的管理员用户的 DN。LDAP_PASSWORD：管理员用户的密码。LDAP_UNIQUE_IDENTIFIER_ATTRIBUTE：用作用户唯一标识符的 LDAP 属性（默认值："uid"）。LDAP_EMAIL_ATTRIBUTE：包含用户电子邮件地址的 LDAP 属性（默认值："mail"）。LDAP_FULL_NAME_ATTRIBUTE：包含用户完整姓名的 LDAP 属性（默认值："cn"）。LDAP_USER_OU：存储用户账户的组织单位（OU）（默认值："people"）。LDAP_SEARCH_BASE：允许覆盖用户搜索的基础 DN（默认值："ou=people"）。如果您使用 FreeIPA，可能需要将其设置为例如cn=users。如果设置了此项，则LDAP_USER_OU将被忽略。
您可以根据 LDAP 模式自定义这些属性。配置 LDAP 后，用户将能够使用他们的 LDAP 凭据登录。LDAP 用户首次登录时，将在 Kviklet 中创建一个具有默认权限的相应用户账户。管理员需要在这些用户首次登录后为他们分配适当的角色。
SAML（仅限企业版）
Kviklet 支持 SAML 2.0 认证。要启用 SAML，请设置以下环境变量：``` SAML_ENABLED=true SAML_ENTITYID=https://your-identity-provider.com SAML_SSOSERVICELOCATION=https://your-identity-provider.com/sso SAML_VERIFICATIONCERTIFICATE=-----BEGIN CERTIFICATE-----\nMIICmzCCAYMCBgF4...\n-----END CERTIFICATE-----
配置详情：
- `SAML_ENABLED`：设置为 `true` 以启用SAML身份验证
- `SAML_ENTITYID`：您的SAML身份提供者的实体ID
- `SAML_SSOSERVICELOCATION`：您的身份提供者的SSO服务URL
- `SAML_VERIFICATIONCERTIFICATE`：用于验证SAML响应的X.509证书（包含BEGIN/END CERTIFICATE行）
您可以选择自定义SAML属性映射：```
SAML_USERATTRIBUTES_EMAILATTRIBUTE=email
SAML_USERATTRIBUTES_NAMEATTRIBUTE=name
SAML_USERATTRIBUTES_IDATTRIBUTE=nameID
您的身份提供者应配置如下：
- 实体 ID:
https://[kviklet_host]/api/saml2/service-provider-metadata/saml - 重定向 URI:
https://[kviklet_host]/api/login/saml2/sso/saml
配置 SAML 后，用户可以通过身份提供者登录。首次登录时，将创建具有默认权限的用户账户。
如果您能正确重定向到 IDP，但随后遇到 CORS 错误，可以通过以下方式将您的 IDP 主机添加到 Kviklet 的允许来源中：``` CORS_ALLOWEDORIGINS=https://[idp_host]
## 配置
### 连接
启动 Kviklet 后，您首先需要配置一个数据库连接。前往 设置 -> 数据库 -> 添加连接。
在这里，您可以配置每个连接的审查要求和执行限制。详情请参阅[审查门禁](#审查门禁)。
#### AWS IAM 认证
Kviklet 支持对 PostgreSQL 和 MySQL 数据库连接使用 IAM 认证，创建新连接时请选择 IAM 认证。
这将移除设置密码的选项，转而使用 AWS 凭证连接到数据库。
Kviklet 使用 AWS 的 `DefaultCredentialsProvider` 查找凭证并生成连接令牌。这意味着所有常见位置（环境变量或关联的实例角色）均可工作，具体顺序在此处有文档说明：https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/DefaultCredentialsProvider.html
此外，您还可以提供一个 Kviklet 将扮演的 AWS 角色 ARN，并使用这些凭证创建临时数据库令牌。这对于连接到与 Kviklet 不在同一 AWS 账户中的数据库尤为有用。要使用此功能，只需在创建或编辑 IAM 认证连接时，在指定字段中输入角色 ARN。留空该字段将使用默认凭证提供者（不进行角色扮演）。
令牌生成时使用的 AWS 区域是从您的连接 URL 推断的，因此没有设置选项。
要了解如何为您的数据库设置 IAM 认证，请遵循 AWS 官方文档：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html
主要要点有两个：
- 创建具有 IAM 认证选项和正确权限的数据库用户
- 创建一个 IAM 策略，允许 AWS 实体为该用户生成令牌
### 审查门禁
默认情况下，Kviklet 允许简单的审查计数配置。您可以配置特定连接上的审批请求需要多少个审批才能执行。
请求的审批状态是根据每个审查者的最新操作计算的。如果审查者批准后稍后要求更改，则只计算更改请求——他们之前的批准将被移除。编辑请求始终会重置所有先前的批准，确保未经审查的更改无法执行。同样，如果执行失败（例如由于 SQL 语法错误），批准也会被重置，以便更正并重新批准请求，无需创建新请求。
您还可以为每个连接配置**最大执行次数**限制，以控制单个已批准请求可以执行的次数。默认为 1。设置为 0 允许无限次执行。失败执行不计入此限制。
#### 基于角色的审查要求（企业版）
使用 Kviklet 企业版许可证，您可以配置单个连接需要具有特定角色的用户进行审批。这允许您，例如，要求维护特定数据库的团队进行审批，或者将敏感连接置于 DBA 或管理层审批之后。
**工作原理：**
每个连接都有一个**所需总审查数**（`numTotalRequired`），它是一个基础值——不考虑角色所需的最少不同审批数。此外，您可以添加**角色要求**，指定必须有多少名来自某个特定角色的用户进行审批（例如，“1 名来自 DBA，1 名来自安全”）。
只有当**两个**条件都满足时，请求才被批准：
- 不同审批人的总数达到 `numTotalRequired`
- 每个角色要求分别满足
如果某个用户属于多个角色，则该用户的一次审批将计入所有匹配的角色要求。不过，它仍然只计入总审批数中的一次。
**示例：** 一个连接需要总共 3 个审批，其中包括 1 个 DBA 和 1 个安全角色的审批。一个同时拥有 DBA 和安全角色的用户进行审批——这满足了两个角色要求，但只计入所需 3 个总审批数中的 1 个。仍然需要另外两个来自任何用户的审批。
如果您企业版许可证过期，现有的基于角色的审查要求将继续生效，但无法再修改。您只能删除它们以回退到简单的总审查数配置。
### 角色
Kviklet 内置 3 个角色：默认角色、管理员和开发者。
- 默认角色提供对所有连接和请求的读取权限。此角色分配给每个用户且无法移除。不过，您可以随意更改此角色的权限。
- 管理员有权创建和编辑连接，以及添加新用户并设置其权限。
- 开发者可以创建请求，以及审批、评论请求，当然还有执行实际语句。
您可以自定义角色，例如，仅授予某个角色对特定连接或一组数据库连接的访问权限。
这在以下场景中很有用：例如，您有不同的团队负责不同的数据库，并希望更精细地控制访问权限。
#### 创建新角色
创建新角色流程如下。前往 设置 -> 角色 -> 添加角色。
对于大多数角色而言，默认设置不太重要，您可以只授予用户读取和角色查看权限，并保持其他不变。
更有趣的是为连接添加单个权限。在此，您首先添加一个选择器来选择特定连接。这可以是一个特定的 ID，或者您可以使用通配符 `*` 匹配多个连接。例如，如果您想要一个角色可以访问所有开发数据库（如果您也使用 Kviklet 管理这些数据库的访问），您可以使用像 `dev-*` 这样的选择器，并确保连接的 ID 设置正确。
当然，您也可以为您组织内不同团队制定自己的系统。
### 角色同步（企业版）
自动从您的身份提供商组同步用户角色。此功能需要企业版许可证。
**配置** 在 设置 > 角色同步 中完成：
- **启用角色同步**：开启/关闭同步
- **同步模式**：
- **完全同步** - 用户角色与其 IdP 组映射（加上默认角色）完全匹配
- **增量同步** - IdP 组添加角色但不会移除现有角色
- **仅首次登录** - 角色仅在首次登录时同步，此后手动更改将保留
- **组属性**：包含组成员身份信息的 IdP 属性（默认：`groups`）
- **角色映射**：将 IdP 组名称（例如 `engineering`）映射到 Kviklet 角色
#### OIDC 设置
配置您的 OIDC 提供者，使其在 ID 令牌中包含 `groups` 声明：
- **Keycloak**：
Keycloak 默认不将组包含在令牌中，因此您需要为客户端添加一个映射器。
1. 在左侧菜单中导航到 **Clients**
2. 选择您的 Kviklet 客户端
3. 进入 **Client scopes** 选项卡
4. 点击专用作用域（例如 `kviklet-dedicated`）
5. 进入 **Mappers** 选项卡
6. 点击 **Add mapper** → **By configuration**
7. 选择 **Group Membership**
8. 配置映射器：
| 设置 | 值 |
|---------|-------|
| 名称 | `groups` |
| 令牌声明名称 | `groups` |
| 完整组路径 | **关闭** |
| 添加到 ID 令牌 | **开启** |
| 添加到访问令牌 | **开启** |
| 添加到用户信息 | **开启** |
9. 点击 **Save**
> **重要：** “令牌声明名称”必须与 Kviklet 角色同步设置中配置的“组属性”匹配（默认：`groups`）。
- **其他 OIDC 提供者**：添加一个组映射器/声明，使用户的组成员身份信息包含在 ID 令牌中。这通常是在提供者的管理界面中完成的。
如果您遇到问题，欢迎创建一个 issue，我们尚未尝试过所有 OIDC 提供者（至少目前没有），并且不同提供者的实现可能存在细微差异，可能需要更新 Kviklet 这边。
#### LDAP 设置
LDAP 角色同步使用 `memberOf` 属性：
1. 确保您的 LDAP 服务器已启用 `memberOf` 覆盖
2. 在 Kviklet 中将 **组属性** 设置为 `memberOf`
3. 然后从用户属性中的 `memberOf` 属性提取组名称。
#### SAML 设置
配置您的 SAML IdP，使其在断言中包含组信息：
1. 添加一个属性语句，映射用户组成员身份
2. 在 Kviklet 中设置 **组属性** 以匹配您的 SAML 属性名称
3. 然后从用户属性中的 SAML 属性提取组名称。
### 通知
您可以配置 Kviklet 向 Slack 或 Teams 频道发送通知。这对于通知您的团队有新的待审查请求非常有用。您可以在 设置 -> 通用 -> 通知设置 中配置此功能。
#### Slack
要配置 Slack 通知，您需要创建一个 Slack 应用并为其启用 webhook。您可以按照此处的说明操作：https://api.slack.com/messaging/webhooks
#### Teams
Teams 通知使用 Power Automate **工作流** webhook。Kviklet 发送一个自适应卡片，webhook 模板会将其发布到您的频道。
**推荐：使用工作流模板**
1. 在 Teams 中，打开您想要接收通知的频道，点击频道名称旁边的 **...**，选择 **工作流**（或添加 **工作流** 应用）。
2. 搜索并创建 **“向频道发送 webhook 警报”** 模板。
3. 按提示登录，然后选择目标团队和频道，创建工作流。
4. 打开触发器步骤，复制生成的 **HTTP POST URL**。
5. 将该 URL 粘贴到 Kviklet 的 设置 -> 通用 -> 通知设置 中，点击保存。
**备选：手动构建工作流**
如果您更喜欢自行构建流程（或模板不可用）：
1. 频道 **...** -> **工作流** -> 创建一个触发器为 **“收到 Teams webhook 请求时”** 的流程。
2. 添加操作 **Microsoft Teams -> “在聊天或频道中发布卡片”**。
3. 将操作的 **自适应卡片** 字段设置为表达式 `string(triggerBody())`，以便发布 Kviklet 发送的卡片。
4. 选择目标团队和频道，**保存**，然后从触发器步骤复制 **HTTP POST URL**。
目前可用的通知有：
- 需要审批的新请求
- 请求上的新审批
#### 基础 URL 配置
当 Kviklet 运行在反向代理或 Kubernetes 入站控制器后面时，通知链接可能使用内部 IP 地址而非您的公共域名。Kviklet 尝试通过查看传入请求来追踪正确的 URL，但某些反向代理未正确设置转发头。要解决此问题，请显式设置基础 URL：```
KVIKLET_BASE_URL=https://kviklet.example.com
这确保所有通知链接指向正确的公共URL。
日志
默认情况下，Kviklet 会将人类可读的（漂亮）日志写入标准输出，这在直接阅读或通过 docker logs 查看时非常方便。
如果将日志发送到集中式系统（Elasticsearch、Loki、Datadog、CloudWatch 等），则可以改用结构化的 JSON 日志，这种日志更容易索引和查询。通过环境变量设置格式：```
One of: ecs (Elastic Common Schema), logstash, gelf (Graylog)
LOGGING_STRUCTURED_FORMAT_CONSOLE=ecs
## Encryption
如果你不希望凭据以明文形式存储在数据库中，建议你在 Kviklet 的 Postgres 数据库上启用数据库加密。对于大多数托管服务提供商来说，这只需勾选一个复选框即可。
然而，如果 Kviklet 数据库以某种方式被攻破，这将是一个巨大的安全风险，因为它包含了可能所有生产数据存储的数据库凭据。因此，你可以启用静态凭据加密。
为此，只需设置这两个环境变量。```
ENCRYPTION_ENABLED=true
ENCRYPTION_KEY_CURRENT=some-secret
Kviklet 会在启动时加密所有现有凭据，并使用该密钥用于你将来创建的连接。
密钥轮换
如果你想轮换密钥，只需为之前的密钥添加另一个变量并更改当前密钥即可：``` ENCRYPTION_KEY_PREVIOUS=some-secret ENCRYPTION_KEY_CURRENT=another-secret
Kviklet 将在启动时重新加密所有连接，这样你就可以在移除之前的密钥后重新启动容器。
## API 密钥
Kviklet 支持使用 API 密钥进行程序化访问。这是一个仅限企业版的功能，需要有效的许可证。你可以在“设置 -> API 密钥”部分创建 API 密钥。
使用方法如下：```bash
curl --location '[kviklet_host]/api/connections/' \
--header 'Authorization: Bearer your-api-key'
API 密钥继承创建该密钥的用户的权限。目前只有管理员可以管理 API 密钥，并且使用 API 密钥执行的所有操作都会归因于创建该密钥的用户。
一些基本的 API 文档可以在 [kviklet_host]/api/swagger-ui/index.html 找到。但请注意，这仍在开发中，API 可能在未来的版本中发生变化。
最终真相在代码中，因此您可以随时查看控制器以了解 API 是如何定义的。如果您有任何问题，欢迎提出 issue。
实验性功能
目前有两个实验性功能。它们主要是基于社区反馈构建的。欢迎尝试这些功能并提供任何意见。我们希望未来能进一步开发这些功能，并使其与核心审批流程良好配合。
Kubernetes Exec
如果您想使用 Kubernetes Exec 功能，您必须创建一个单独的 Kubernetes 连接。Kviklet 将使用部署的 Pod 的用户来执行命令。因此，请确保该用户具有在您要访问的 Pod 上执行命令的必要权限。
Kviklet 还使用 /bin/sh 来执行命令，因此您需要确保您的 Pod 具有 shell，或者至少在 /bin/sh 处有一个符号链接。如果这对您造成困扰，欢迎提出 issue，我们有可能使其可配置或找到其他解决方案。
Kubernetes 命令仅等待 5 秒的输出；如果命令耗时更长，Kviklet 将等待最多一小时，然后超时。这是一个临时解决方案，我们正在研究使用 WebSocket 来提高响应速度，并可能启用终端会话。
代理，仅 Postgres
如果您创建临时访问请求，您可以使用 kviklet 管理的代理并通过您选择的数据库客户端来运行查询，而不是使用 Web 界面。 为此，容器使用端口 5438-6000，因此您需要暴露这些端口。 然后，用户可以创建临时访问请求，并在审批通过后点击 "Start Proxy"。每个请求将获得一个端口、一个用户以及一个临时密码。凭借这些信息，用户可以连接到数据库。Kviklet 会验证临时用户和密码，并将所有请求代理到数据库上的底层用户。任何执行的语句都会记录在审计日志中，就像通过 Web 界面运行一样。 请注意，代理端的消息解析尚未在所有客户端上测试，因此如果您遇到例如语句未记录的问题，欢迎提出 issue。
Postgres 代理 - TLS
Kviklet 终止与数据库的 TLS 连接。这意味着默认情况下，进出代理本身的任何流量都未加密。 如果您希望 kviklet 重新加密流量，可以通过设置以下环境变量为 Kviklet 提供代理的 TLS 证书和密钥：``` PROXY_TLS_CERTIFICATE_SOURCE=env PROXY_TLS_CERTIFICATE_CERT=your-certificate PROXY_TLS_CERTIFICATE_KEY=your-key
或者，您可以使用文件：```
PROXY_TLS_CERTIFICATE_SOURCE=file
PROXY_TLS_CERTIFICATE_CERT_FILE=path/to/cert.pem
PROXY_TLS_CERTIFICATE_KEY_FILE=path/to/key.pem
无论哪种方式，证书和密钥都必须以pem格式存储。
疑问？贡献？
如果您有任何疑问、想要提供反馈或需要设置帮助，请加入我们的Discord社区。您也可以为错误报告和功能请求创建一个GitHub issue。
如果您想贡献，请随时fork并为小改动创建PR。如果您计划更大的功能，我期望提前在GitHub issue或Discord上进行讨论。
您也可以通过[email protected]联系我。