|
| 1 | +# Database node authentication and authorization |
| 2 | + |
| 3 | +Node authentication in the {{ ydb-short-name }} cluster ensures that database nodes are authenticated when making service requests to other nodes via the gRPC protocol. Node authorization ensures that the privileges required by the service requests are checked and granted during request processing. These service calls include database node registration within the cluster and access to [dynamic configuration](../../maintenance/manual/dynamic-config.md) information. The use of node authorization is recommended for all {{ ydb-short-name }} clusters, as it helps prevent unauthorized access to data by adding nodes controlled by an attacker to the cluster. |
| 4 | + |
| 5 | +Database node authentication and authorization are performed in the following order: |
| 6 | + |
| 7 | +1. The database node being started opens a gRPC connection to one of the cluster storage nodes specified in the `--node-broker` command-line option. The connection uses the TLS protocol, and the certificate of the running node is used as the client certificate for the connection. |
| 8 | +2. The storage node and the database node perform mutual authentication checks using the TLS protocol: the certificate trust chain is checked, and the hostname is matched against the value of the "Subject Name" field of the certificate. |
| 9 | +3. The storage node checks the "Subject" field of the certificate for compliance with the requirements [set up through settings](../../reference/configuration/client_certificate_authorization.md) in the static configuration. |
| 10 | +4. If the above checks are successful, the connection from the database node is considered authenticated, and it is assigned a security identifier - [SID](../../concepts/glossary.md#access-sid), which is determined by the settings. |
| 11 | +5. The database node uses the established gRPC connection to register with the cluster through the corresponding service request. When registering, the database node sends its network address intended to be used for communication with other cluster nodes. |
| 12 | +6. The storage node checks whether the SID assigned to the gRPC connection is in the list of acceptable ones. If this check is successful, the storage node registers the database node within the cluster, saving the association between the network address of the registered node and its identifier. |
| 13 | +7. The database node joins the cluster by connecting via its network address and providing the node ID it received during registration. Attempts to join the cluster by nodes with unknown network addresses or IDs are blocked by other nodes. |
| 14 | + |
| 15 | +Below are the steps required to enable the node authentication and authorization feature. |
| 16 | + |
| 17 | +## Configuration prerequisites |
| 18 | + |
| 19 | +1. The deployed {{ ydb-short-name }} cluster must have [gRPC traffic encryption](../../reference/configuration/tls.md#grpc) configured to use the TLS protocol. |
| 20 | +1. When preparing node certificates for a cluster where you plan to use the node authorization feature, uniform rules must be used for populating the "Subject" field of the certificates. This allows the identification of certificates issued for the cluster nodes. For more information, see the [certificate verification rules documentation](../../reference/configuration/client_certificate_authorization.md). |
| 21 | + |
| 22 | + {% note info %} |
| 23 | + |
| 24 | + The proposed [example script](https://github.com/ydb-platform/ydb/blob/main/ydb/deploy/tls_cert_gen/) generates self-signed certificates for {{ ydb-short-name }} nodes and ensures that the "Subject" field is populated with the value `O=YDB` for all node certificates. The configuration examples provided below are prepared for certificates with this specific "Subject" field configuration, but feel free to use your real organization name instead. |
| 25 | + |
| 26 | + {% endnote %} |
| 27 | + |
| 28 | +1. The command-line parameters for [starting database nodes](../../devops/manual/initial-deployment.md#start-dynnode) must include options that specify the paths to the trusted CA certificate, the node certificate, and the node key files. The required additional command-line options are shown in the table below. |
| 29 | + |
| 30 | + | **Command-line option** | **Description** | |
| 31 | + |-------------------------|-----------------| |
| 32 | + | `--grpc-ca` | Path to the trusted certification authority file `ca.crt` | |
| 33 | + | `--grpc-cert` | Path to the node certificate file `node.crt` | |
| 34 | + | `--grpc-key` | Path to the node secret key file `node.key` | |
| 35 | + |
| 36 | + Below is an example of the complete command to start the database node, including the extra options for gRPC TLS key and certificate files: |
| 37 | + |
| 38 | + ```bash |
| 39 | + /opt/ydb/bin/ydbd server --yaml-config /opt/ydb/cfg/config.yaml --tenant /Root/testdb \ |
| 40 | + --grpcs-port 2136 --grpc-ca /opt/ydb/certs/ca.crt \ |
| 41 | + --grpc-cert /opt/ydb/certs/node.crt --grpc-key /opt/ydb/certs/node.key \ |
| 42 | + --ic-port 19002 --ca /opt/ydb/certs/ca.crt \ |
| 43 | + --mon-port 8766 --mon-cert /opt/ydb/certs/web.pem \ |
| 44 | + --node-broker grpcs://<ydb1>:2135 \ |
| 45 | + --node-broker grpcs://<ydb2>:2135 \ |
| 46 | + --node-broker grpcs://<ydb3>:2135 |
| 47 | + ``` |
| 48 | + |
| 49 | +## Enabling database node authentication and authorization |
| 50 | + |
| 51 | +To enable mandatory database node authorization, add the following configuration blocks to the [static cluster configuration](../../reference/configuration/index.md) file: |
| 52 | + |
| 53 | +1. At the root level, add the `client_certificate_authorization` block to define the requirements for the "Subject" field of trusted node certificates. For example: |
| 54 | + |
| 55 | + ```yaml |
| 56 | + client_certificate_authorization: |
| 57 | + request_client_certificate: true |
| 58 | + client_certificate_definitions: |
| 59 | + - member_groups: ["registerNode@cert"] |
| 60 | + subject_terms: |
| 61 | + - short_name: "O" |
| 62 | + values: ["YDB"] |
| 63 | + ``` |
| 64 | + |
| 65 | + Add other certificate validation settings [as defined in the documentation](../../reference/configuration/client_certificate_authorization.md), if required. |
| 66 | + |
| 67 | + If the certificate is successfully verified and the components of the "Subject" field comply with the requirements defined in the `subject_terms` sub-block, the connection will be assigned the access subjects listed in the `member_groups` parameter. To distinguish these subjects from other user groups and accounts, their names typically have the `@cert` suffix. |
| 68 | + |
| 69 | +1. Add the `register_dynamic_node_allowed_sids` element to the cluster authentication settings `security_config` block, and list the subjects permitted for database node registration. For internal technical reasons, the list must include the `root@builtin` element. Example: |
| 70 | + |
| 71 | + ```yaml |
| 72 | + domains_config: |
| 73 | + ... |
| 74 | + security_config: |
| 75 | + enforce_user_token_requirement: true |
| 76 | + monitoring_allowed_sids: |
| 77 | + ... |
| 78 | + administration_allowed_sids: |
| 79 | + ... |
| 80 | + viewer_allowed_sids: |
| 81 | + ... |
| 82 | + register_dynamic_node_allowed_sids: |
| 83 | + - "root@builtin" # required for internal technical reasons |
| 84 | + - "registerNode@cert" |
| 85 | + ``` |
| 86 | + |
| 87 | + For more detailed information on configuring cluster authentication parameters, see the [relevant documentation section](../../reference/configuration/index.md#security-access-levels). |
| 88 | + |
| 89 | +1. Deploy the static configuration files on all cluster nodes either manually, or [using the Ansible playbook action](../ansible/update-config.md). |
| 90 | + |
| 91 | +1. Perform the rolling restart of storage nodes by [using ydbops](../../reference/ydbops/scenarios.md) or [Ansible playbook action](../ansible/restart.md). |
| 92 | + |
| 93 | +1. Perform the rolling restart of database nodes through ydbops or Ansible playbooks. |
0 commit comments