</details>

### DB 설정

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]

현재로서는 컨테이너를 GitHub 패키지에 게시하고 있으므로, 이 모든 설정이 완료되면 `ghcr.io/kviklet/kviklet:main`을 실행할 수 있습니다. Kviklet이 기본적으로 사용하는 포트인 `8080`을 매핑하는 것을 잊지 마세요.

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

google client id와 secret은 다음 google 안내를 따라 하면 쉽게 얻을 수 있습니다:
https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid

유효한 redirect URI의 경우 다음을 구성해야 합니다: https://[kviklet_host]/api/login/oauth2/code/google
Allowed Origins의 경우, 간단히 호스팅된 kviklet url을 입력하면 됩니다.

이 환경 변수들을 설정한 후에는 조직의 모든 사람이 sign in with google 버튼으로 로그인할 수 있습니다. 하지만 기본적으로 아무 권한도 없으므로, 한 번 로그인한 후에 역할을 할당해야 합니다.

#### Keycloak

대신 Keycloak으로 SSO를 설정하려면 다음 4개의 환경 변수를 설정해야 합니다:```
KVIKLET_IDENTITYPROVIDER_CLIENTID
KVIKLET_IDENTITYPROVIDER_CLIENTSECRET
KVIKLET_IDENTITYPROVIDER_TYPE=keycloak
KVIKLET_IDENTITYPROVIDER_ISSUERURI=http://[host]:[port]/realms/[realm]

GitHub OAuth App을 https://github.com/settings/developers 에서 생성하고 다음을 구성하세요:

- Authorization callback URL: `https://[kviklet_host]/api/login/oauth2/code/github`
- Homepage URL: 호스팅된 Kviklet URL

`KVIKLET_IDENTITYPROVIDER_GITHUB_ALLOWEDORGS`는 **필수**입니다 (Kviklet은 이것 없이는 시작을 거부합니다). GitHub OAuth App은 OAuth 흐름을 완료하는 사람을 제한할 수 없으므로, Kviklet은 인증 후 `/user/orgs`를 호출하여 허용 목록에 있는 하나 이상의 조직 구성원이 아닌 사용자를 거부합니다 (대소문자 구분 없음, 처음 100개 조직 확인).

조직 확인이 사용자의 구성원 자격을 확인하려면, 사용자가 OAuth 동의 화면에서 각 허용된 조직 옆의 **Grant** (또는 **Request**)를 클릭해야 합니다. 조직에서 "Restrict third-party OAuth applications"가 활성화된 경우, 조직 소유자도 구성원의 구성원 자격이 표시되기 전에 OAuth 앱을 한 번 승인해야 합니다.

Kviklet은 `read:user`, `user:email` 및 `read:org` 스코프를 요청합니다. 이메일은 항상 `/user/emails`에서 읽으며 `primary && verified` 항목만 허용되므로, 비공개 이메일 주소를 가진 사용자도 성공적으로 로그인할 수 있습니다.

#### 기타 OIDC 제공자

기타 OIDC 호환 제공자 (GitLab, Auth0, Okta 등)는 Keycloak과 유사하게 작동해야 합니다. 선택한 유형에 따라 `redirect URI`가 변경되므로, `gitlab`을 선택하면 `https://[kviklet_host]/api/login/oauth2/code/gitlab`이 됩니다.
문제가 발생하면 언제든지 이슈를 생성해 주세요. 우리는 (아직) 세상의 모든 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

구성 세부 사항:

- `SAML_ENABLED`: SAML 인증을 활성화하려면 `true`로 설정합니다
- `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

## 구성

### 연결

Kviklet을 시작한 후 먼저 데이터베이스 연결을 구성해야 합니다. Settings -> Databases -> Add Connection으로 이동하세요.

![Add Connection](https://assets.kitploit.com/production/public/readmes/7140/3ded2a0b23e5d2f02feb21a854263c91dedea25a789fb75ab8342384c4e39b52.png)
![Add Connection](https://assets.kitploit.com/production/public/readmes/7140/585238c9eddad8ed4e2440096ce0616445a6696e1042f58676a1d0b038edde7f.png)

여기에서 각 연결에 대한 검토 요구 사항과 실행 제한을 구성할 수 있습니다. 자세한 내용은 [Review Gates](#review-gates)를 참조하세요.

#### AWS IAM AUTH

Kviklet은 Postgres, MySQL 및 MariaDB 데이터베이스 연결에 IAM Auth 사용을 지원합니다. 이를 위해서는 새 연결을 생성할 때 IAM Auth를 선택하세요.

![IAM Auth](https://assets.kitploit.com/production/public/readmes/7140/14ed42bd639eb9b0ba81b22850e277703f2da9495dd101f68066f95fc51f291c.png)
![IAM Auth](https://assets.kitploit.com/production/public/readmes/7140/5a60a3a9ae527e11679f3c33c787caba4c80b379ddc463db1f871288408517e1.png)

이렇게 하면 비밀번호를 설정하는 옵션이 제거되고 대신 AWS 자격 증명을 사용하여 데이터베이스에 연결합니다.

Kviklet은 AWS의 `DefaultCredentialsProvider`를 사용하여 자격 증명을 찾고 연결을 위한 토큰을 생성합니다. 이는 모든 일반적인 위치(환경 변수 또는 연결된 인스턴스 역할)가 작동해야 함을 의미하며, 정확한 순서는 여기에 문서화되어 있습니다: https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/DefaultCredentialsProvider.html

또한 Kviklet이 수임할 AWS 역할 ARN을 제공하고, 해당 자격 증명을 사용하여 임시 DB 토큰을 생성할 수 있습니다. 이는 Kviklet과 동일한 AWS 계정에 없는 데이터베이스에 연결할 때 특히 유용합니다. 이 기능을 사용하려면 IAM Auth 연결을 생성하거나 편집할 때 지정된 필드에 역할 ARN을 입력하기만 하면 됩니다. 필드를 비워두면 기본 자격 증명 공급자를 사용합니다(역할 수임 없음).

토큰 생성 중에 사용할 AWS 리전은 연결 URL에서 유추되므로 설정할 옵션이 없습니다.

데이터베이스에 대한 IAM Auth를 설정하는 방법을 알아보려면 공식 AWS 문서를 따르세요: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html
주요 두 가지 사항은 다음과 같습니다:

- IAM auth 옵션과 올바른 권한을 가진 DB 사용자 생성
- AWS 엔터티가 이 사용자에 대한 토큰을 생성할 수 있도록 허용하는 IAM 정책 생성

### Review Gates

기본적으로 Kviklet은 간단한 검토 횟수 구성을 허용합니다. 특정 연결에 대한 요청이 실행되기 전에 필요한 승인 수를 구성할 수 있습니다.

요청의 승인 상태는 각 검토자의 최신 작업을 기반으로 계산됩니다. 검토자가 승인한 후 나중에 변경을 요청하면 변경 요청만 계산되며, 이전 승인은 제거됩니다. 요청을 편집하면 항상 모든 이전 승인이 재설정되어 검토 없이 변경 사항이 실행될 수 없도록 보장합니다. 마찬가지로 실행이 실패하면(예: SQL 구문 오류로 인해) 승인이 재설정되어 새 요청을 생성하지 않고도 요청을 수정하고 다시 승인할 수 있습니다.

또한 연결당 **최대 실행** 제한을 구성하여 단일 승인된 요청이 실행될 수 있는 빈도를 제어할 수 있습니다. 기본값은 1입니다. 이를 0으로 설정하면 무제한 실행이 가능합니다. 실패한 실행은 이 제한에 포함되지 않습니다.

#### 역할 기반 검토 요구 사항 (Enterprise)

Kviklet Enterprise 라이선스를 사용하면 개별 연결에 특정 역할을 가진 사용자의 승인을 요구하도록 구성할 수 있습니다. 이를 통해 예를 들어 특정 데이터베이스를 유지 관리하는 팀의 승인을 요구하거나 민감한 연결을 DBA 또는 관리 승인 뒤에 두도록 게이트할 수 있습니다.

**작동 방식:**

각 연결에는 **필요한 총 검토 수** (`numTotalRequired`)가 있으며, 이는 역할에 관계없이 필요한 최소 고유 승인 수의 하한선 역할을 합니다. 그 위에 특정 역할을 가진 사용자로부터 몇 개의 승인이 있어야 하는지 지정하는 **역할 요구 사항**을 추가할 수 있습니다(예: "DBA에서 1개, Security에서 1개").

요청은 **두** 조건이 모두 충족될 때만 승인됩니다:

- 고유 승인 총 수가 `numTotalRequired`를 충족
- 각 역할 요구 사항이 개별적으로 충족

사용자가 여러 역할에 속한 경우, 해당 사용자의 단일 승인은 일치하는 모든 역할 요구 사항에 계산됩니다. 그러나 총 수에는 하나의 승인으로만 계산됩니다.

**예시:** 연결에 DBA에서 1개, Security에서 1개를 포함하여 총 3개의 승인이 필요합니다. DBA와 Security 역할을 모두 가진 사용자가 승인하면 두 역할 요구 사항을 모두 충족하지만 필요한 총 3개 승인 중 1개로만 계산됩니다. 모든 사용자로부터 2개의 추가 승인이 여전히 필요합니다.

엔터프라이즈 라이선스가 만료되면 기존 역할 기반 검토 요구 사항은 계속 적용되지만 더 이상 수정할 수 없습니다. 간단한 총 검토 수 구성으로 되돌리려면 해당 요구 사항을 제거할 수만 있습니다.

### 역할

Kviklet은 Default, Admins, Developers의 3가지 역할과 함께 제공됩니다.

- 기본 역할은 모든 연결 및 Requests에 대한 Read 액세스를 제공합니다. 이 역할은 모든 사용자에게 할당되며 제거할 수 없습니다. 그러나 이 역할의 권한은 원하는 대로 변경할 수 있습니다.
- Admins는 연결을 생성 및 편집하고, 새 사용자를 추가하고 권한을 설정할 수 있는 권한을 가집니다.
- Developers는 Requests를 생성하고 승인 및 댓글을 달 수 있으며 물론 실제 명령문을 실행할 수 있습니다.

역할을 사용자 정의하고 예를 들어 특정 연결 또는 DB 연결 그룹에만 액세스 권한을 부여할 수 있습니다.
이는 예를 들어 서로 다른 데이터베이스를 가진 여러 팀이 있고 해당 데이터베이스에 대한 액세스를 더 세분화하여 제어하려는 경우에 유용합니다.

#### 새 역할 생성

새 역할을 생성하는 방법은 다음과 같습니다. Settings -> Roles -> Add Role로 이동하세요.

![Add Role](https://assets.kitploit.com/production/public/readmes/7140/a91b79287c0b3130b83bdde1c059f49b89c5d43a1c0deae33b211ea427956f8e.png)
![Add Role](https://assets.kitploit.com/production/public/readmes/7140/c535ac152759bb21bea04a0968ce43fa7bf946c7699feca23c71f9eaba41ceaf.png)

기본 설정은 대부분의 역할에 그다지 관련이 없으며 User Read 및 RoleView Access를 부여하고 그대로 두면 됩니다.
더 흥미로운 것은 Connections에 대한 개별 권한을 추가하는 것입니다. 여기에서 먼저 특정 연결을 선택하는 선택기를 추가합니다. 이는 특정 id일 수도 있고 `*` 와일드카드를 사용하여 여러 연결을 일치시킬 수도 있습니다. 예를 들어 모든 dev 데이터베이스에 액세스할 수 있는 역할을 원하는 경우(kviklet으로 해당 데이터베이스에 대한 액세스도 관리하는 경우) `dev-*`와 같은 선택기를 사용하고 연결의 id가 올바르게 설정되었는지 확인하세요.

물론 조직 내의 다양한 팀을 위해 사용하는 시스템을 직접 만들 수도 있습니다.

### 역할 동기화 (Enterprise)

ID 공급자 그룹에서 사용자 역할을 자동으로 동기화합니다. 이 기능을 사용하려면 엔터프라이즈 라이선스가 필요합니다.

**구성**은 Settings > Role Sync에서 수행합니다:

- **Enable Role Sync**: 동기화 켜기/끄기
- **Sync Mode**:
  - **Full Sync** - 사용자 역할이 IdP 그룹 매핑과 정확히 일치(기본 역할 포함)
  - **Additive** - IdP 그룹이 역할을 추가하지만 기존 역할을 제거하지 않음
  - **First Login Only** - 첫 로그인 시에만 역할이 동기화되며, 이후 수동 변경 사항은 유지됨
- **Groups Attribute**: 그룹 멤버십을 포함하는 IdP 속성(기본값: `groups`)
- **Role Mappings**: 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. 매퍼 구성:

  | Setting             | Value    |
  | ------------------- | -------- |
  | Name                | `groups` |
  | Token Claim Name    | `groups` |
  | Full group path     | **OFF**  |
  | Add to ID token     | **ON**   |
  | Add to access token | **ON**   |
  | Add to userinfo     | **ON**   |
  9. **Save** 클릭

  > **중요:** "Token Claim Name"은 Kviklet의 Role Sync 설정에 구성된 "Groups Attribute"와 일치해야 합니다(기본값: `groups`).

- **기타 OIDC 공급자**: ID 토큰에 사용자의 그룹 멤버십을 포함하는 groups 매퍼/클레임을 추가하세요. 이는 일반적으로 공급자의 관리 UI에서 수행됩니다.

  문제가 발생하면 이슈를 생성해 주세요. 우리는 (아직) 세상의 모든 OIDC 공급자를 시도해보지 않았으며 Kviklet 측에서 업데이트가 필요할 수 있는 구현상의 약간의 차이가 있을 수 있습니다.

#### LDAP 설정

LDAP 역할 동기화는 `memberOf` 속성을 사용합니다:

1. LDAP 서버에 `memberOf` 오버레이가 활성화되어 있는지 확인
2. Kviklet에서 **Groups Attribute**를 `memberOf`로 설정
3. 그런 다음 그룹 이름은 사용자 속성의 `memberOf` 속성에서 추출됩니다.

#### SAML 설정

SAML IdP가 어설션에 그룹을 포함하도록 구성하세요:

1. 사용자 그룹 멤버십을 매핑하는 속성 명령문 추가
2. Kviklet의 **Groups Attribute**를 SAML 속성 이름과 일치하도록 설정
3. 그런 다음 그룹 이름은 사용자 속성의 SAML 속성에서 추출됩니다.

### 알림

Kviklet이 Slack 또는 Teams의 채널로 알림을 보내도록 구성할 수 있습니다. 이는 검토가 필요한 새 요청에 대해 팀에 알리는 데 유용합니다. Settings -> General -> Notification Settings에서 구성할 수 있습니다.

#### Slack

Slack 알림을 구성하려면 Slack App을 생성하고 웹훅을 활성화해야 합니다. 다음 지침을 따를 수 있습니다: https://api.slack.com/messaging/webhooks

#### Teams

Teams 알림은 Power Automate **Workflow** 웹훅을 사용합니다. Kviklet은 Adaptive Card를 전송하며, 웹훅 템플릿이 이를 채널에 게시합니다.

**권장: 워크플로 템플릿 사용**

1. Teams에서 알림을 받을 채널을 열고 채널 이름 옆의 **...**를 클릭한 후 **Workflows**를 선택합니다(또는 **Workflows** 앱 추가).
2. **"Send webhook alerts to a channel"** 템플릿을 검색하여 생성합니다.
3. 메시지가 표시되면 로그인한 후 대상 Team과 Channel을 선택하고 워크플로를 생성합니다.
4. 트리거 단계를 열고 생성된 **HTTP POST URL**을 복사합니다.
5. URL을 Kviklet의 Settings -> General -> Notification Settings에 붙여넣고 저장을 클릭합니다.

**대안: 워크플로 수동 구축**

직접 플로우를 구축하려는 경우(또는 템플릿을 사용할 수 없는 경우):

1. 채널 **...** -> **Workflows** -> **"When a Teams webhook request is received"** 트리거로 플로우를 생성합니다.
2. **Microsoft Teams -> "Post card in a chat or channel"** 액션을 추가합니다.
3. 액션의 **Adaptive Card** 필드를 `string(triggerBody())` 표현식으로 설정하여 Kviklet이 보내는 카드를 게시하도록 합니다.
4. 대상 Team과 Channel을 선택하고 **Save**한 후 트리거 단계에서 **HTTP POST URL**을 복사합니다.

현재 다음과 같은 알림이 있습니다:

- 승인이 필요한 새 Requests
- 요청에 대한 새 승인

#### Base URL 구성

리버스 프록시 또는 Kubernetes Ingress 뒤에서 Kviklet을 실행할 때 알림 링크가 공용 도메인 대신 내부 IP 주소를 사용할 수 있습니다. Kviklet은 들어오는 요청을 확인하여 올바른 URL을 추적하려고 시도하지만 일부 리버스 프록시는 Forwarded 헤더를 올바르게 설정하지 않습니다. 이 문제를 해결하려면 base URL을 명시적으로 설정하세요:```
KVIKLET_BASE_URL=https://kviklet.example.com

Kviklet는 시작할 때 텔레메트리가 켜져 있는지 여부를 나타내는 한 줄을 로그에 기록합니다.

**전송되는 항목.** 모든 이벤트에는 무작위 인스턴스 id(Kviklet의 데이터베이스에 한 번 생성되어 저장됨), Kviklet에 접근하는 기본 URL(위 참조, 흔히 내부 호스트 이름), 그리고 Kviklet 버전이 포함됩니다. 사용자는 인스턴스 범위로 한정된 불투명 id로만 식별되므로 고유 사용자 수는 셀 수 있지만, 이메일 주소나 이름은 절대 전송되지 않습니다. 정확한 이벤트와 그 속성은 `backend/src/main/kotlin/dev/kviklet/kviklet/telemetry/TelemetryEvent.kt`에 정의되어 있습니다.

**절대 전송되지 않는 항목.** 쿼리, 구문, 결과, 명령 출력, 오류 메시지, 연결 이름, 호스트 이름, 자격 증명, 요청 제목이나 설명, 댓글, 그리고 사용자 또는 역할 이름.

### 로깅

기본적으로 Kviklet는 사람이 읽을 수 있는(pretty) 로그를 stdout에 기록하며, 이는 로그를 직접 읽거나 `docker logs`를 통해 읽을 때 편리합니다.

로그를 중앙 시스템(Elasticsearch, Loki, Datadog, CloudWatch, …)으로 전송하는 경우, 인덱싱과 쿼리가 더 쉬운 구조화된 **JSON 로그**로 전환할 수 있습니다. 환경 변수를 통해 형식을 설정하세요:```
# One of: ecs (Elastic Common Schema), logstash, gelf (Graylog)
LOGGING_STRUCTURED_FORMAT_CONSOLE=ecs

Kviklet는 시작 시 기존의 모든 자격 증명을 암호화하고, 앞으로 생성하는 연결에 해당 secret을 사용합니다.

### 키 교체

키를 교체하려면 이전 키에 대한 변수를 하나 더 추가하고 현재 키를 변경하면 됩니다:```
ENCRYPTION_KEY_PREVIOUS=some-secret
ENCRYPTION_KEY_CURRENT=another-secret

API 키는 이를 생성한 사용자의 권한을 상속받습니다. 현재는 관리자만 API 키를 관리할 수 있으며, API 키로 수행되는 모든 작업은 해당 키를 생성한 사용자에게 귀속됩니다.

일부 기초적인 API 문서는 `[kviklet_host]/api/swagger-ui/index.html`에서 확인할 수 있습니다. 다만 이는 작업 진행 중인 문서이며, 향후 버전에서 API가 변경될 수 있다는 점을 유의하시기 바랍니다.

결국 진실은 코드에 있으므로, API가 어떻게 정의되어 있는지 확인하려면 언제든 컨트롤러를 살펴볼 수 있습니다. 궁금한 점이 있으면 언제든 이슈를 열어주세요.

## 실험적 기능

현재 두 가지 실험적 기능이 있습니다. 이들은 주로 커뮤니티 피드백을 바탕으로 만들어졌습니다. 편하게 사용해 보시고 의견이 있으시면 남겨주세요. 향후 이를 더 발전시키고 핵심 승인 흐름과 잘 작동하도록 만들고자 합니다.

### Kubernetes Exec

Kubernetes Exec 기능을 사용하려면 별도의 kubernetes 연결을 생성해야 합니다. Kviklet은 배포된 pod의 사용자를 사용하여 명령을 실행합니다. 따라서 해당 사용자가 접근하려는 pod에서 명령을 실행할 수 있는 필요한 권한을 가지고 있는지 확인하세요.

Kviklet은 또한 명령 실행에 /bin/sh를 사용하므로, pod에 셸이 있거나 최소한 /bin/sh에 심볼릭 링크가 있는지 확인해야 합니다. 이것이 불편하시다면 언제든 이슈를 열어주세요. 설정 가능하게 만들거나 다른 해결책을 찾을 수도 있습니다.

Kubernetes 명령은 출력을 5초 동안만 기다립니다. 명령이 그보다 오래 걸리면 Kviklet은 명령이 타임아웃되기 전까지 최대 한 시간 동안 기다립니다. 이는 임시 방편이며, 더 반응성을 높이고 잠재적으로 터미널 세션을 활성화하기 위해 websocket을 검토하고 있습니다.

### Proxy - Postgres, MariaDB, MySQL (Enterprise)

임시 접근 요청을 생성한 경우, 웹 인터페이스를 사용하는 대신 kviklet이 관리하는 프록시를 통해 쿼리를 실행하고 원하는 DB 클라이언트를 사용할 수 있습니다.
프록시는 엔터프라이즈 기능입니다. 유효한 라이선스가 필요하며, 관리자가 Settings -> General -> Database Proxy에서 추가로 활성화해야 합니다.
이를 위해 컨테이너는 고정 포트(기본적으로 5432 및 3306, `kviklet.proxy.postgres.port` 및 `kviklet.proxy.mysql.port`로 구성 가능)에서 수신 대기하므로 해당 포트를 노출해야 합니다.
그런 다음 사용자는 임시 접근 요청을 생성하고, 승인되면 "Start Proxy"를 클릭할 수 있습니다. 각 요청에는 임시 사용자 이름과 비밀번호가 부여되며, Kviklet은 사용자 이름을 기준으로 각 연결을 해당 요청으로 라우팅합니다. 이를 통해 데이터베이스에 연결할 수 있습니다. Kviklet은 임시 사용자와 비밀번호를 검증하고 모든 요청을 데이터베이스의 실제 사용자에게 프록시합니다. 실행된 모든 구문은 웹 인터페이스를 통해 실행된 것처럼 감사 로그에 기록됩니다.

참고: 프록시는 현재 결과 추적을 지원하지 않습니다. 따라서 실행된 구문은 기록되지만 결과나 구문의 성공 또는 실패 여부는 기록되지 않습니다.

![Postgres Proxy](https://assets.kitploit.com/production/public/readmes/7140/153b5b3e85c492079f01f1ffda490a53df2be01cfd808553abc511eb90fc1731.png)
![Postgres Proxy](https://assets.kitploit.com/production/public/readmes/7140/2c886b3cb184b13bbee9120ca5f1cdd9f45dd7743c5cf7a01fe8d5f7474d507a.png)

#### Proxy - TLS

Kviklet은 데이터베이스에 대한 TLS 연결을 종료합니다. 즉, 기본적으로 프록시 자체와 주고받는 모든 트래픽은 암호화되지 않습니다.  
Kviklet이 트래픽을 다시 암호화하도록 하려면 다음 환경 변수를 설정하여 프록시용 TLS 인증서와 키를 Kviklet에 제공할 수 있습니다:```
PROXY_TLS_CERTIFICATE_SOURCE=env
PROXY_TLS_CERTIFICATE_CERT=your-certificate
PROXY_TLS_CERTIFICATE_KEY=your-key

어느 쪽이든 인증서와 키는 [pem 형식](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail)으로 저장해야 합니다.

## 질문이 있으신가요? 기여하고 싶으신가요?

질문이 있거나, 피드백을 제공하고 싶거나, 설정에 도움이 필요하시면 [Discord 커뮤니티](https://discord.gg/7SmPJfeP6e)에 참여해 주세요. 버그 보고와 기능 요청은 [GitHub 이슈](https://github.com/kviklet/kviklet/issues)를 생성하셔도 됩니다.

기여하고 싶으시다면, 작은 부분은 자유롭게 포크하고 PR을 생성해 주세요. 더 큰 기능을 계획하고 계시다면, GitHub 이슈나 Discord에서 미리 논의해 주시면 감사하겠습니다.

[email protected]로 저에게 연락하실 수도 있습니다.