> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-detect-table-modification.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> USER 관련 문서
# CREATE USER
[사용자 계정](/ko/concepts/features/security/access-rights#user-account-management)을 생성합니다.
구문:
```sql theme={null}
CREATE USER [IF NOT EXISTS | OR REPLACE] name1 [, name2 [,...]] [ON CLUSTER cluster_name]
[{VALID UNTIL datetime | VALID FOR interval}]
[NOT IDENTIFIED | IDENTIFIED {[WITH {plaintext_password | sha256_password | sha256_hash | double_sha1_password | double_sha1_hash}] BY {'password' | 'hash'}} | WITH NO_PASSWORD | {WITH ldap SERVER 'server_name'} | {WITH kerberos [REALM 'realm']} | {WITH ssl_certificate CN 'common_name' | SAN 'TYPE:subject_alt_name'} | {WITH ssh_key BY KEY 'public_key' TYPE 'ssh-rsa|...'} | {WITH http SERVER 'server_name' [SCHEME 'Basic']} [{VALID UNTIL datetime | VALID FOR interval}] [GRANTS (privilege ON object [,...])]
[, {[{plaintext_password | sha256_password | sha256_hash | ...}] BY {'password' | 'hash'}} | {ldap SERVER 'server_name'} | {...} | ... [,...]]]
[HOST {LOCAL | NAME 'name' | REGEXP 'name_regexp' | IP 'address' | LIKE 'pattern'} [,...] | ANY | NONE]
[IN access_storage_type]
[ROLE role [,...]]
[DEFAULT ROLE role [,...]]
[DEFAULT DATABASE database | NONE]
[GRANTEES {user | role | ANY | NONE} [,...] [EXCEPT {user | role} [,...]]]
[SETTINGS variable [= value] [MIN [=] min_value] [MAX [=] max_value] [READONLY | WRITABLE] | PROFILE 'profile_name'] [,...]
```
`ON CLUSTER` 절을 사용하면 클러스터 전체에 사용자를 생성할 수 있습니다. 자세한 내용은 [분산 DDL](/ko/reference/statements/distributed-ddl)을 참조하십시오.
## 식별
사용자를 식별하는 방법은 여러 가지입니다:
* `IDENTIFIED WITH no_password`
* `IDENTIFIED WITH plaintext_password BY 'qwerty'`
* `IDENTIFIED WITH sha256_password BY 'qwerty'` or `IDENTIFIED BY 'password'`
* `IDENTIFIED WITH sha256_hash BY 'hash'` or `IDENTIFIED WITH sha256_hash BY 'hash' SALT 'salt'`
* `IDENTIFIED WITH double_sha1_password BY 'qwerty'`
* `IDENTIFIED WITH double_sha1_hash BY 'hash'`
* `IDENTIFIED WITH bcrypt_password BY 'qwerty'`
* `IDENTIFIED WITH bcrypt_hash BY 'hash'`
* `IDENTIFIED WITH ldap SERVER 'server_name'`
* `IDENTIFIED WITH kerberos` or `IDENTIFIED WITH kerberos REALM 'realm'`
* `IDENTIFIED WITH ssl_certificate CN 'mysite.com:user'`
* `IDENTIFIED WITH ssh_key BY KEY 'public_key' TYPE 'ssh-rsa', KEY 'another_public_key' TYPE 'ssh-ed25519'`
* `IDENTIFIED WITH http SERVER 'http_server'` or `IDENTIFIED WITH http SERVER 'http_server' SCHEME 'basic'`
* `IDENTIFIED BY 'qwerty'`
비밀번호 복잡성 요구 사항은 [config.xml](/ko/concepts/features/configuration/server-config/configuration-files)에서 수정할 수 있습니다. 아래는 비밀번호가 최소 12자 이상이고 숫자 1개를 포함해야 하도록 설정하는 구성 예시입니다. 각 비밀번호 복잡성 규칙에는 비밀번호와 매칭할 정규식과 해당 규칙에 대한 설명이 필요합니다.
```xml theme={null}
.{12}
be at least 12 characters long
\p{N}
contain at least 1 numeric character
```
ClickHouse Cloud에서는 기본적으로 비밀번호가 다음 복잡성 요구 사항을 충족해야 합니다.
* 최소 12자 이상이어야 합니다
* 숫자를 최소 1개 포함해야 합니다
* 대문자를 최소 1개 포함해야 합니다
* 소문자를 최소 1개 포함해야 합니다
* 특수 문자를 최소 1개 포함해야 합니다
## 예시
1. 다음 사용자 이름은 `name1`이며 비밀번호가 필요하지 않습니다. 당연히 보안상 그다지 안전하지 않습니다:
```sql theme={null}
CREATE USER name1 NOT IDENTIFIED
```
2. plaintext 비밀번호를 지정하려면 다음과 같이 합니다:
```sql theme={null}
CREATE USER name2 IDENTIFIED WITH plaintext_password BY 'my_password'
```
비밀번호는 `/var/lib/clickhouse/access`의 SQL 텍스트 파일에 저장되므로 `plaintext_password`를 사용하는 것은 바람직하지 않습니다. 대신 다음 예시와 같이 `sha256_password`를 사용하십시오...
3. 가장 일반적인 방법은 SHA-256으로 해시된 비밀번호를 사용하는 것입니다. `IDENTIFIED WITH sha256_password`를 지정하면 ClickHouse가 비밀번호를 대신 해시합니다. 예시는 다음과 같습니다:
```sql theme={null}
CREATE USER name3 IDENTIFIED WITH sha256_password BY 'my_password'
```
이제 `name3` 사용자는 `my_password`로 로그인할 수 있지만, 비밀번호는 위의 해시값으로 저장됩니다. 다음 SQL 파일이 `/var/lib/clickhouse/access`에 생성되며 서버 시작 시 실행됩니다:
```bash theme={null}
/var/lib/clickhouse/access $ cat 3843f510-6ebd-a52d-72ac-e021686d8a93.sql
ATTACH USER name3 IDENTIFIED WITH sha256_hash BY '0C268556C1680BEF0640AAC1E7187566704208398DA31F03D18C74F5C5BE5053' SALT '4FB16307F5E10048196966DD7E6876AE53DE6A1D1F625488482C75F14A5097C7';
```
사용자 이름에 대한 해시값과 해당 salt 값을 이미 생성한 경우 `IDENTIFIED WITH sha256_hash BY 'hash'` 또는 `IDENTIFIED WITH sha256_hash BY 'hash' SALT 'salt'`를 사용할 수 있습니다. `SALT`를 사용해 `sha256_hash`로 식별하는 경우 해시는 'password'와 'salt'를 이어 붙인 값으로 계산해야 합니다.
4. `double_sha1_password`는 일반적으로 필요하지 않지만, 이를 요구하는 클라이언트(MySQL interface 등)와 함께 작업할 때 유용합니다:
```sql theme={null}
CREATE USER name4 IDENTIFIED WITH double_sha1_password BY 'my_password'
```
ClickHouse는 다음 쿼리를 생성하고 실행합니다:
```response theme={null}
CREATE USER name4 IDENTIFIED WITH double_sha1_hash BY 'CCD3A959D6A004B9C3807B728BC2E55B67E10518'
```
5. `bcrypt_password`는 비밀번호 저장에 가장 안전한 옵션입니다. 이 방식은 [bcrypt](https://en.wikipedia.org/wiki/Bcrypt) 알고리즘을 사용하며, 비밀번호 해시가 유출되더라도 무차별 대입 공격에 강합니다.
```sql theme={null}
CREATE USER name5 IDENTIFIED WITH bcrypt_password BY 'my_password'
```
이 방법에서는 비밀번호 길이가 72자로 제한됩니다.
해시 계산과 비밀번호 검증에 필요한 연산량과 시간을 정의하는 bcrypt work factor 매개변수는 서버 구성에서 수정할 수 있습니다:
```xml theme={null}
12
```
work factor는 4에서 31 사이여야 하며, 기본값은 12입니다.
인증 빈도가 높은 애플리케이션의 경우,
더 높은 work factor에서 발생하는
bcrypt의 계산 오버헤드를 고려하여
다른 인증 방식을 검토하십시오.
6. 비밀번호 타입은 생략할 수도 있습니다:
```sql theme={null}
CREATE USER name6 IDENTIFIED BY 'my_password'
```
이 경우 ClickHouse는 서버 구성에 지정된 기본 비밀번호 타입을 사용합니다:
```xml theme={null}
sha256_password
```
사용 가능한 비밀번호 타입은 다음과 같습니다: `plaintext_password`, `sha256_password`, `double_sha1_password`.
7. 여러 인증 방법을 지정할 수 있습니다:
```sql theme={null}
CREATE USER user1 IDENTIFIED WITH plaintext_password by '1', bcrypt_password by '2', plaintext_password by '3''
```
참고:
1. 이전 버전의 ClickHouse는 여러 인증 방법 구문을 지원하지 않을 수 있습니다. 따라서 ClickHouse 서버에 이러한 사용자가 있는 상태에서 이를 지원하지 않는 버전으로 다운그레이드하면, 해당 사용자를 사용할 수 없게 되고 일부 사용자 관련 작업도 정상적으로 동작하지 않게 됩니다. 문제 없이 다운그레이드하려면, 다운그레이드 전에 모든 사용자가 하나의 인증 방법만 사용하도록 설정해야 합니다. 또는 적절한 절차 없이 서버를 다운그레이드했다면, 문제가 있는 사용자는 삭제해야 합니다.
2. 보안상의 이유로 `no_password`는 다른 인증 방법과 함께 사용할 수 없습니다. 따라서
`no_password`는 쿼리에서 유일한 인증 방법일 때만 지정할 수 있습니다.
## 사용자 호스트
사용자 호스트는 ClickHouse 서버에 연결을 설정할 수 있는 호스트입니다. 호스트는 `HOST` 쿼리 섹션에서 다음과 같은 방식으로 지정할 수 있습니다.
* `HOST IP 'ip_address_or_subnetwork'` — 사용자는 지정된 IP 주소 또는 [서브넷](https://en.wikipedia.org/wiki/Subnetwork)에서만 ClickHouse 서버에 연결할 수 있습니다. 예시: `HOST IP '192.168.0.0/16'`, `HOST IP '2001:DB8::/32'`. 프로덕션 환경에서는 `host` 및 `host_regexp`를 사용하면 추가 지연 시간이 발생할 수 있으므로 `HOST IP` 요소(IP 주소 및 해당 마스크)만 지정하십시오.
* `HOST ANY` — 사용자는 어디서나 연결할 수 있습니다. 기본 옵션입니다.
* `HOST LOCAL` — 사용자는 로컬에서만 연결할 수 있습니다.
* `HOST NAME 'fqdn'` — 사용자 호스트를 FQDN으로 지정할 수 있습니다. 예를 들어 `HOST NAME 'mysite.com'`입니다.
* `HOST REGEXP 'regexp'` — 사용자 호스트를 지정할 때 [pcre](http://www.pcre.org/) 정규식을 사용할 수 있습니다. 예를 들어 `HOST REGEXP '.*\.mysite\.com'`입니다.
* `HOST LIKE 'template'` — [LIKE](/ko/reference/functions/regular-functions/string-search-functions#like) 연산자를 사용해 사용자 호스트를 필터링할 수 있습니다. 예를 들어 `HOST LIKE '%'`는 `HOST ANY`와 같고, `HOST LIKE '%.mysite.com'`는 `mysite.com` 도메인의 모든 호스트를 필터링합니다.
호스트를 지정하는 또 다른 방법은 사용자 이름 뒤에 `@` 구문을 사용하는 것입니다. 예시는 다음과 같습니다.
* `CREATE USER mira@'127.0.0.1'` — `HOST IP` 구문과 동일합니다.
* `CREATE USER mira@'localhost'` — `HOST LOCAL` 구문과 동일합니다.
* `CREATE USER mira@'192.168.%.%'` — `HOST LIKE` 구문과 동일합니다.
ClickHouse는 `user_name@'address'` 전체를 하나의 사용자 이름으로 처리합니다. 따라서 기술적으로는 동일한 `user_name`에 대해 `@` 뒤의 구성이 다른 여러 사용자를 만들 수 있습니다. 그러나 이렇게 하는 것은 권장하지 않습니다.
## VALID UNTIL 절
인증 방법의 만료 날짜와 선택적으로 시간을 지정할 수 있습니다. 문자열을 매개변수로 받습니다. 날짜 및 시간에는 `YYYY-MM-DD [hh:mm:ss] [timezone]` 포맷을 사용하는 것이 좋습니다. 여기서 `[timezone]`은 `+09:00`과 같은 숫자 오프셋이거나 `UTC`, `GMT`, `Z`, `MSK`, `MSD` 중 하나여야 합니다. `Asia/Tokyo`와 같은 이름 기반 IANA 시간대는 인식되지 않습니다(아래 참고 참조). 기본적으로 이 매개변수의 값은 `'infinity'`입니다. 허용되는 마감 시각 범위는 `1900-01-01 00:00:00 UTC`부터 `9999-12-31 09:59:59 UTC`까지입니다. 이는 모든 시간대에서 9999년 범위를 벗어나지 않는 가장 늦은 시점이므로, 저장된 시점을 표시할 때 값이 제한되지 않습니다. 과거의 마감 시각은 자격 증명이 이미 만료되었음을 의미합니다. `1970-01-01 00:00:01 UTC` 이전의 마감 시각은 "이미 만료됨" 표시로만 허용됩니다. 이 값은 Unix epoch 1초 후(`1970-01-01 00:00:01 UTC`)인 가장 이른 만료 시점으로 정규화되므로, `SHOW CREATE USER`는 작성한 마감 시각 대신 해당 시점을 표시합니다. 해당 시점 이후의 마감 시각은 정확하게 저장됩니다.
마감 시각은 절대 시점으로 저장되지만, `SHOW CREATE USER` 및 [`system.users`](/ko/reference/system-tables/users)는 이를 server 또는 session 시간대로 표시합니다. 따라서 동일한 저장 시점도 구성이 다른 server에서는 서로 다른 현지 시각 텍스트로 나타납니다. 예를 들어 위의 정규화된 만료 시점은 `UTC` server에서는 `1970-01-01 00:00:01`로, `Pacific/Kiritimati` server에서는 `1970-01-01 14:00:01`로 표시됩니다. 적용 시에는 항상 표시값이 아닌 저장된 시점을 사용합니다.
절의 위치에 따라 적용되는 인증 방법가 결정됩니다.
* `IDENTIFIED` 절 앞에 있거나(또는 쿼리에 인증 방법가 전혀 지정되지 않은 경우) 있으면, 마감 시각은 사용자의 모든 인증 방법에 적용되는 사용자 수준의 마감 시각입니다.
* 인증 방법 뒤에 있으면 마감 시각은 해당 메서드에만 적용됩니다. 따라서 전체 `IDENTIFIED` 목록 뒤에 작성된 절은 마지막 메서드에만 바인딩되며, 앞선 메서드에는 만료가 적용되지 않습니다.
예시:
* `CREATE USER name1 VALID UNTIL '2025-01-01'`
* `CREATE USER name1 VALID UNTIL '2025-01-01 12:00:00 UTC'`
* `CREATE USER name1 VALID UNTIL '2025-01-01 12:00:00 +09:00'`
* `CREATE USER name1 VALID UNTIL 'infinity'`
* `CREATE USER name1 VALID UNTIL '2025-01-01' IDENTIFIED WITH plaintext_password BY 'password_1', bcrypt_password BY 'password_2'` — 사용자 수준의 마감 시각은 두 메서드 모두에 적용됩니다.
* `CREATE USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID UNTIL '2025-01-01'` — 마감 시각은 `bcrypt_password` 메서드에만 적용되며, `plaintext_password`는 만료되지 않습니다.
날짜 및 시간 문자열은 `parseDateTimeBestEffort`로 파싱되며, 이 함수는 `UTC`, `GMT`, `Z`, `MSK`, `MSD` 시간대 토큰과 `+09:00` 또는 `-05:00`과 같은 숫자 오프셋만 인식합니다. `Asia/Tokyo` 또는 `Europe/London`과 같은 이름 기반 IANA 시간대는 지원되지 않습니다. 또한 고정 오프셋은 일광 절약 시간을 적용하는 지역의 IANA 시간대와 동일하지 않으므로, 인코딩하는 특정 날짜에 맞는 올바른 오프셋을 계산해야 합니다.
## VALID FOR 절
`VALID FOR` 절은 `VALID UNTIL`을 간편하게 줄여 쓴 표현입니다. 절대 날짜와 시간 대신 [인터벌](/ko/reference/data-types/special-data-types/interval)을 지정할 수 있으며, 쿼리 실행 시점의 현재 시간에 해당 인터벌을 더해 만료 마감 시각을 계산합니다. 결과는 `VALID UNTIL` 형식으로 저장되므로 `SHOW CREATE USER`는 항상 해석된 절대 마감 시각을 표시합니다. `VALID UNTIL`을 사용할 수 있는 모든 위치에서 사용할 수 있으며, 동일한 배치 규칙을 따릅니다. 즉, `IDENTIFIED` 앞에 있거나 인증 방법이 없는 경우에는 모든 메서드에 적용되는 사용자 수준의 마감 시각이 되며, 인증 방법 뒤에 있으면 해당 메서드에만 적용됩니다. 마감 시각은 초 단위 정밀도로 저장되고 적용되므로 하위 초 단위 인터벌(`NANOSECOND`, `MICROSECOND`, `MILLISECOND`)은 허용되지 않으며, 허용되는 최소 단위는 `SECOND`입니다. 음수 인터벌은 자격 증명이 이미 만료되었음을 표시하는 용도로 사용할 수 있습니다. 계산된 마감 시각이 `1970-01-01 00:00:01 UTC`보다 이르면 가장 이른 만료 시점으로 정규화되며, 이후 `SHOW CREATE USER`는 이를 표시합니다. 이 값은 [`VALID UNTIL`](#valid-until-clause)에 설명된 대로 서버 또는 세션 시간대로 표시됩니다.
예시:
* `CREATE USER name1 VALID FOR INTERVAL 1 DAY`
* `CREATE USER name1 VALID FOR INTERVAL 3 MONTH`
* `CREATE USER name1 VALID FOR INTERVAL 1 DAY + INTERVAL 12 HOUR`
* `CREATE USER name1 VALID FOR INTERVAL 30 DAY IDENTIFIED WITH plaintext_password BY 'password_1', bcrypt_password BY 'password_2'` — 사용자 수준의 마감 시각은 두 메서드 모두에 적용됩니다.
* `CREATE USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID FOR INTERVAL 30 DAY` — 마감 시각은 `bcrypt_password` 메서드에만 적용되며, `plaintext_password`는 만료되지 않습니다.
## GRANTS 절
특정 인증 방법로 인증된 세션에서 사용할 수 있는 접근 권한을 제한할 수 있습니다. [GRANT](/ko/reference/statements/grant) SQL 문과 동일한 형식의 권한 목록을 괄호 안에 지정합니다. 이 절은 인증 방법 뒤에(`VALID UNTIL` 절이 있으면 그 뒤에) 지정하며 해당 메서드에만 적용됩니다.
사용자가 이러한 인증 방법로 로그인하면 세션의 접근 권한은 사용자의 접근 권한(권한이 부여된 역할의 권한 포함)과 절에 나열된 권한의 교집합이 됩니다. 이 절은 접근 권한을 추가하지 않습니다. 나열된 권한이 사용자에게 부여되지 않았다면 세션에도 해당 권한이 없습니다. 이러한 메서드로 인증된 세션은 권한을 부여할 수도 없으며(`GRANT OPTION`은 교집합에 포함되지 않음) 역할을 관리할 수도 없습니다. 역할 관리에는 역할 생성, 변경, 삭제, 권한 부여 및 취소뿐 아니라 사용자에게 기본적으로 활성화되는 역할을 변경하는 작업(`SET DEFAULT ROLE` 및 `ALTER USER ... DEFAULT ROLE`)도 포함되며, 이 역시 거부됩니다.
`EXECUTE AS`는 세션의 주체를 전환하므로, 가장하여 실행되는 SQL 문은 로그인한 사용자의 권한이 아니라 **대상** 사용자의 접근 권한과 나열된 권한의 교집합으로 제한됩니다. 제한 자체는 절대 해제되지 않으며, 가장하려면 사용자에게 `IMPERSONATE ON target`이 부여되어 있고 절에도 나열되어 있어야 합니다. 따라서 제한된 자격 증명은 동일 사용자의 제한 없는 자격 증명보다 더 많은 권한을 얻을 수 없습니다.
이를 통해 애플리케이션용 토큰을 편리하게 만들 수 있습니다. 즉, 만료일과 제한된 권한 집합을 가진 사용자에 연결된 추가 자격 증명입니다. 이 자격 증명은 `system.query_log` 및 `system.processes`에 사용자로 표시되고, 사용자가 삭제되면 작동을 멈추며, 사용자가 권한을 잃으면 접근 권한도 잃습니다.
**강제 적용은 initiator에서만 수행됩니다.** 인증 방법 `GRANTS` 제한과 `VALID UNTIL` 만료는 쿼리를 수신하는 노드(initiator)에서만 강제 적용됩니다. 이는 클러스터의 다른 노드로 전파되지 않으므로, 클러스터 전체의 실행을 제한하기 위해 이 절에 의존하지 마십시오. 원격 노드는 일반적인 역할 범위를 유지합니다. 이 절은 `users.xml`에서도 사용할 수 없습니다. [쿼리 결과 캐시](/ko/concepts/features/performance/caches/query-cache)는 사용자의 모든 인증 방법에서 공유됩니다. 캐시 항목은 사용자와 역할별로 분리되며, 캐시 적중 시 세션이 로그인한 메서드의 `GRANTS`에 대해 다시 확인하지 않습니다.
예시:
* `CREATE USER name1 IDENTIFIED BY 'qwerty' GRANTS (SELECT ON db.*)`
* `ALTER USER name1 ADD IDENTIFIED WITH plaintext_password BY 'app_token' VALID UNTIL '2026-12-31' GRANTS (SELECT ON db.table, INSERT ON db.table)`
제한은 로그인 시점에 확정되는 인증 방법의 속성입니다. `ALTER USER`로 절을 변경하면 새 세션에 영향을 주며, 이미 수립된 세션에는 영향을 주지 않습니다.
`READ ON S3('s3://bucket/.*')`와 같은 소스 필터가 적용된 권한 부여는 아직 이 절에서 지원되지 않습니다. 교집합은 소스 필터를 불투명한 문자열로 비교하므로 한 필터를 다른 필터로 좁힐 수 없습니다. 따라서 이러한 권한 부여는 액세스 권한이 부여되지 않은 채 조용히 처리되는 대신 거부됩니다.
이 절은 서버가 자격 증명을 순수하게 로컬에서 확인하는 인증 방법에서만 지원됩니다. 확인 과정에서 외부 시스템에 연결하는 메서드(`ldap`, `kerberos`, `http`, `jwt`의 경우 서명 키를 가져오기 위해 연결할 수 있음)의 경우 이 절은 거부됩니다. 여러 인증 방법가 동일한 자격 증명을 허용하면 다른 메서드에 대해 자격 증명을 다시 확인하여 제한을 적용하는데, 외부 시스템을 추가로 확인하는 것은 안전하지 않습니다. 따라서 동일한 자격 증명을 허용하는 다른 메서드가 제한을 우회할 수 있습니다.
동일한 유효 자격 증명이 둘 이상의 인증 방법에서 허용되면, 로그인은 이들 모두에 의해 실패 시 차단 방식으로 제한됩니다. 세션은 일치하는 모든 메서드의 `GRANTS` 교집합을 얻고, 해당 `VALID UNTIL` 중 가장 이른 시점에 만료됩니다. 가장 이른 `VALID UNTIL`이 이미 지났더라도 우선 적용됩니다. 단일 일치 메서드가 만료된 경우와 정확히 동일하게 로그인이 거부되므로, 토큰의 만료로 공유 자격 증명이 더 광범위한 메서드의 권한이나 유효 기간을 조용히 얻는 일이 없습니다.
이 조합은 위에서 외부 검증 메서드에 이 절 자체가 허용되지 않는 것과 같은 이유로, server가 로컬에서 검증하는 인증 방법 간에만 확인됩니다. 외부 검증 메서드에서 자격 증명을 다시 확인하려면 외부 시스템에 안전하지 않은 추가 probe를 수행해야 하기 때문입니다. 따라서 동일한 사용자의 외부 검증 메서드(`ldap`, `kerberos`, `http`, `jwt`)에서도 같은 자격 증명이 허용되더라도, 해당 메서드의 `VALID UNTIL`은 이 조합에 포함되지 않으며, 그 메서드에 구성된 더 이른 만료 시점이 로컬 검증 메서드를 통해 획득한 세션을 단축하지 않습니다.
## GRANTEES 절
이 사용자에게 [GRANT OPTION](/ko/reference/statements/grant#granting-privilege-syntax)과 함께 필요한 모든 접근 권한이 부여된 경우, 이 사용자로부터 [권한](/ko/reference/statements/grant#privileges)을 받을 수 있는 사용자 또는 역할을 지정합니다. `GRANTEES` 절의 옵션은 다음과 같습니다.
* `user` — 이 사용자가 권한을 부여할 수 있는 사용자를 지정합니다.
* `role` — 이 사용자가 권한을 부여할 수 있는 역할을 지정합니다.
* `ANY` — 이 사용자는 누구에게나 권한을 부여할 수 있습니다. 기본값입니다.
* `NONE` — 이 사용자는 누구에게도 권한을 부여할 수 없습니다.
`EXCEPT` 표현식을 사용하면 특정 사용자나 역할을 제외할 수 있습니다. 예를 들어 `CREATE USER user1 GRANTEES ANY EXCEPT user2`는 `user1`에 `GRANT OPTION`과 함께 일부 권한이 부여된 경우, `user2`를 제외한 누구에게나 해당 권한을 부여할 수 있음을 의미합니다.
## 예시
비밀번호 `qwerty`로 보호된 사용자 계정 `mira`를 생성합니다:
```sql theme={null}
CREATE USER mira HOST IP '127.0.0.1' IDENTIFIED WITH sha256_password BY 'qwerty';
```
`mira`는 ClickHouse 서버가 실행 중인 호스트에서 클라이언트 앱을 실행해야 합니다.
사용자 계정 `john`을 생성하고 역할을 할당합니다:
```sql theme={null}
CREATE USER john ROLE role1, role2;
```
사용자 계정 `john`을 생성하고, 역할을 할당한 다음 그중 일부를 기본 역할로 설정합니다:
```sql theme={null}
CREATE USER john ROLE role1, role2 DEFAULT ROLE role1;
```
또는
```sql theme={null}
CREATE USER john ROLE role1, role2 DEFAULT ROLE ALL EXCEPT role2;
```
사용자 계정 `john`을 생성하고, `jack` 계정 사용자에게 자신의 권한을 부여할 수 있도록 합니다:
```sql theme={null}
CREATE USER john GRANTEES jack;
```
쿼리 매개변수를 사용해 사용자 계정 `john`을 생성하세요:
```sql theme={null}
SET param_user=john;
CREATE USER {user:Identifier};
```