diff --git a/ydb/docs/build.sh b/ydb/docs/build.sh
index b93f0e6c2a70..8c80809d5750 100755
--- a/ydb/docs/build.sh
+++ b/ydb/docs/build.sh
@@ -36,10 +36,10 @@ echo "Output directory: $DIR"
 
 if ! yfm -i . -o $DIR --allowHTML  --apply-presets; then
   echo
-  echo "================================"
-  echo "YFM build completed with ERRORS!"
-  echo "================================"
-  echo "It may be necessary to use the latest version of npm. Run the command `nvm use v22.9.0` to update it."
+  echo '================================'
+  echo 'YFM build completed with ERRORS!'
+  echo '================================'
+  echo 'It may be necessary to use the latest version of npm. Run the command `nvm use v22.9.0` to update it.'
   exit 1
 fi
 
diff --git a/ydb/docs/en/core/devops/manual/node-authorization.md b/ydb/docs/en/core/devops/manual/node-authorization.md
new file mode 100644
index 000000000000..8cf53f21fa52
--- /dev/null
+++ b/ydb/docs/en/core/devops/manual/node-authorization.md
@@ -0,0 +1,92 @@
+# Database node authentication and authorization
+
+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.
+
+Database node authentication and authorization are performed in the following order:
+
+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.
+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.
+3. The storage node checks the "Subject" field of the certificate for compliance with the requirements set in the static configuration.
+4. If the above checks are successful, the connection from the database node is considered authenticated, and it is assigned a special [SID](../../concepts/glossary.md#access-sid) determined by the settings.
+5. The database node uses the established gRPC connection to register with the cluster and obtain the dynamic configuration through the corresponding service requests.
+6. The storage node checks whether the SID assigned to the connection is in the list of acceptable ones. If this check is successful, the storage node performs the requested action.
+
+Below are the steps required to enable the node authentication and authorization feature.
+
+## Configuration prerequisites
+
+1. The deployed {{ ydb-short-name }} cluster must have [gRPC traffic encryption](../../reference/configuration/tls.md#grpc) configured to use the TLS protocol.
+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/node-authentication.md).
+
+    {% note info %}
+
+    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.
+
+    {% endnote %}
+
+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.
+
+    | **Command-line option** | **Description** |
+    |-------------------------|-----------------|
+    | `--grpc-ca`             | Path to the trusted certification authority file `ca.crt` |
+    | `--grpc-cert`           | Path to the node certificate file `node.crt` |
+    | `--grpc-key`            | Path to the node secret key file `node.key` |
+
+    Below is an example of the complete command to start the database node, including the extra options for gRPC TLS key and certificate files:
+
+    ```bash
+    /opt/ydb/bin/ydbd server --yaml-config  /opt/ydb/cfg/config.yaml --tenant /Root/testdb \
+        --grpcs-port 2136 --grpc-ca /opt/ydb/certs/ca.crt \
+        --grpc-cert /opt/ydb/certs/node.crt --grpc-key /opt/ydb/certs/node.key \
+        --ic-port 19002 --ca /opt/ydb/certs/ca.crt \
+        --mon-port 8766 --mon-cert /opt/ydb/certs/web.pem \
+        --node-broker grpcs://<ydb1>:2135 \
+        --node-broker grpcs://<ydb2>:2135 \
+        --node-broker grpcs://<ydb3>:2135
+    ```
+
+## Enabling database node authentication and authorization
+
+To enable mandatory database node authorization, add the following configuration blocks to the [static cluster configuration](../../reference/configuration/index.md) file:
+
+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:
+
+    ```yaml
+    client_certificate_authorization:
+      request_client_certificate: true
+      client_certificate_definitions:
+        - member_groups: ["registerNode@cert"]
+          subject_terms:
+          - short_name: "O"
+            values: ["YDB"]
+    ```
+
+    Add other certificate validation settings [as defined in the documentation](../../reference/configuration/node-authentication.md), if required.
+
+    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.
+
+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:
+
+    ```yaml
+    domains_config:
+        ...
+        security_config:
+            enforce_user_token_requirement: true
+            monitoring_allowed_sids:
+            ...
+            administration_allowed_sids:
+            ...
+            viewer_allowed_sids:
+            ...
+            register_dynamic_node_allowed_sids:
+            - "root@builtin" # required for internal technical reasons
+            - "registerNode@cert"
+    ```
+
+    For more detailed information on configuring cluster authentication parameters, see the [relevant documentation section](../../reference/configuration/index.md#security-access-levels).
+
+1. Deploy the static configuration files on all cluster nodes either manually, or [using the Ansible playbook action](../ansible/update-config.md).
+
+1. Perform the rolling restart of storage nodes by [using ydbops](../../reference/ydbops/scenarios.md) or [Ansible playbook action](../ansible/restart.md).
+
+1. Perform the rolling restart of database nodes through ydbops or Ansible playbooks.
diff --git a/ydb/docs/en/core/maintenance/manual/dynamic-config.md b/ydb/docs/en/core/maintenance/manual/dynamic-config.md
index 6a506dcab0df..bbce36dadb89 100644
--- a/ydb/docs/en/core/maintenance/manual/dynamic-config.md
+++ b/ydb/docs/en/core/maintenance/manual/dynamic-config.md
@@ -1,4 +1,4 @@
-## Dynamic cluster configuration
+# Dynamic cluster configuration
 
 Dynamic configuration allows running dynamic [nodes](../../concepts/cluster/common_scheme_ydb#nodes) by configuring them centrally without manually distributing files across the nodes. {{ ydb-short-name }} acts as a configuration management system, providing tools for reliable storage, versioning, and delivery of configurations, as well as a [DSL (Domain Specific Language)](./dynamic-config-selectors.md) for overriding parts of the configuration for specific groups of nodes. The configuration is a YAML document and is an extended version of the static configuration:
 
@@ -8,12 +8,47 @@ Dynamic configuration allows running dynamic [nodes](../../concepts/cluster/comm
 
 This configuration is uploaded to the cluster, where it is reliably stored and delivered to each dynamic node upon startup. [Certain settings](#dynamic-kinds) are updated on the fly without restarting nodes. Using dynamic configuration, you can centrally solve the following tasks:
 
-* Switch logging settings for components for the entire cluster or specific groups of nodes;
-* Enable experimental features (feature flags) on specific databases;
-* Change actor system settings on individual nodes or groups of nodes;
-* And more.
+* Change logging levels for all or specific components across the entire cluster or for specific groups of nodes.
+* Enable experimental features (feature flags) on specific databases.
+* Change actor system settings on individual nodes or groups of nodes.
 
-### Configuration examples {#example}
+## Preparing to use the dynamic configuration {#preparation}
+
+The following tasks should be performed before using the dynamic configuration in the cluster:
+
+1. Enable [database node authentication and authorization](../../devops/manual/node-authorization.md).
+
+1. Export the current settings from the [CMS](../../concepts/glossary.md#cms) in YAML format using the following command if [CMS-based configuration management](cms.md) has been used in the cluster:
+
+    ```bash
+    ./ydbd -s grpcs://<node1.ydb.tech>:2135 --ca-file ca.crt --token-file ydbd-token \
+         admin console configs dump-yaml > dynconfig.yaml
+    ```
+
+    Before running the command shown above, obtain the authentication token using the `ydb auth get-token` command, as detailed in the [cluster initial deployment procedure](../../devops/manual/initial-deployment.md#initialize-cluster).
+
+1. Prepare the initial dynamic configuration file:
+
+   * If there are non-empty CMS settings exported in the previous step, adjust the YAML file with the exported CMS settings:
+      * Add the `metadata` section based on the [configuration example](#example).
+      * Add the `yaml_config_enabled: true` parameter to the `config` section.
+   * If there are no previous CMS-based settings, use the [minimal configuration example](#example).
+   * For clusters using TLS encryption for [actor system interconnect](../../concepts/glossary.md#actor-system-interconnect), add the [interconnect TLS settings](../../reference/configuration/tls.md#interconnect) to the `config` section.
+
+1. Apply the dynamic configuration settings file to the cluster:
+
+    ```bash
+    # Apply the dynconfig.yaml on the cluster
+    {{ ydb-cli }} admin config replace -f dynconfig.yaml
+    ```
+
+{% note info %}
+
+The legacy configuration management via CMS will become unavailable after enabling dynamic configuration support on the {{ ydb-short-name }} cluster.
+
+{% endnote %}
+
+## Configuration examples {#example}
 
 Example of a minimal dynamic configuration for a single-datacenter cluster:
 
@@ -21,70 +56,103 @@ Example of a minimal dynamic configuration for a single-datacenter cluster:
 # Configuration metadata.
 # This field is managed by the server.
 metadata:
- # Cluster name from the cluster_uuid parameter set during cluster installation, or "", if the parameter is not set.
- cluster: unknown
- # Configuration file identifier, always increments by 1 starting from 1.
- # Automatically increases when a new configuration is uploaded to the server.
- version: 1
+  # Cluster name from the cluster_uuid parameter set during cluster installation, or "", if the parameter is not set.
+  cluster: ""
+  # Configuration file identifier, always increments by 1 starting from 0.
+  # Automatically increases when a new configuration is uploaded to the server.
+  version: 0
 # Main cluster configuration. All values here are applied by default unless overridden by selectors.
 # Content is similar to the static cluster configuration.
 config:
-# It must always be set to true when using YAML configuration.
- yaml_config_enabled: true
-# Actor system configuration, as by default, this section is used only by dynamic nodes.
-# Configuration is set specifically for them.
- actor_system_config:
-# Automatic configuration selection for the node based on type and available cores.
- use_auto_config: true
-# HYBRID || COMPUTE || STORAGE — node type.
- node_type: COMPUTE
-# Number of cores.
- cpu_count: 4
-# Root domain configuration of the {{ ydb-short-name }} cluster.
- domains_config:
- domain:
- - name: Root
- storage_pool_types:
- - kind: ssd
- pool_config:
- box_id: 1
- erasure_species: none
- kind: ssd
- pdisk_filter:
- - property:
- - type: SSD
- vdisk_kind: Default
- explicit_mediators: [72075186232426497, 72075186232426498, 72075186232426499]
- explicit_coordinators: [72075186232360961, 72075186232360962, 72075186232360963]
- explicit_allocators: [72075186232492033, 72075186232492034, 72075186232492035]
- state_storage:
- - ssid: 1
- ring:
- nto_select: 5
- node: [1, 2, 3, 4, 5, 6, 7, 8]
- hive_config:
- - hive_uid: 1
- hive: 72057594037968897
-# Channel profile configuration for tablets.
- channel_profile_config:
- profile:
- - profile_id: 0
- channel:
- - &default_channel
- erasure_species: block-4-2
- pdisk_category: 1
- vdisk_category: Default
- - *default_channel
- - *default_channel
+  # It must always be set to true when using YAML configuration.
+  yaml_config_enabled: true
+  # Actor system configuration, as by default, this section is used only by dynamic nodes.
+  # Configuration is set specifically for them.
+  actor_system_config:
+    # Automatic configuration selection for the node based on type and available cores.
+    use_auto_config: true
+    # HYBRID || COMPUTE || STORAGE — node type.
+    node_type: COMPUTE
+    # Number of cores.
+    cpu_count: 14
 allowed_labels: {}
 selector_config: []
 ```
 
 Detailed configuration parameters are described on the [{#T}](../../reference/configuration/index.md) page.
 
-By default, the cluster configuration is empty and has version 1. When applying a new configuration, the uploaded configuration's version is compared and automatically incremented by one.
+By default, the cluster configuration is assigned version 1. When applying a new configuration, the system compares the uploaded configuration's version with the value specified in the YAML file. If the versions match, the current version number is automatically incremented by one.
+
+Below is a more comprehensive example of a dynamic configuration that defines typical global parameters as well as parameters specific to a particular database:
+
+```yaml
+---
+metadata:
+  kind: MainConfig
+  cluster: ""
+  version: 1
+config:
+  yaml_config_enabled: true
+  table_profiles_config:
+    table_profiles:
+    - name: default
+      compaction_policy: default
+      execution_policy: default
+      partitioning_policy: default
+      storage_policy: default
+      replication_policy: default
+      caching_policy: default
+    compaction_policies:
+    - name: default
+    execution_policies:
+    - name: default
+    partitioning_policies:
+    - name: default
+      auto_split: true
+      auto_merge: true
+      size_to_split: 2147483648
+    storage_policies:
+    - name: default
+      column_families:
+      - storage_config:
+          sys_log:
+            preferred_pool_kind: ssd
+          log:
+            preferred_pool_kind: ssd
+          data:
+            preferred_pool_kind: ssd
+    replication_policies:
+    - name: default
+    caching_policies:
+    - name: default
+  interconnect_config:
+    encryption_mode: REQUIRED
+    path_to_certificate_file: "/opt/ydb/certs/node.crt"
+    path_to_private_key_file: "/opt/ydb/certs/node.key"
+    path_to_ca_file: "/opt/ydb/certs/ca.crt"
+allowed_labels:
+  node_id:
+    type: string
+  host:
+    type: string
+  tenant:
+    type: string
+selector_config:
+- description: Custom settings for testdb
+  selector:
+    tenant: /cluster1/testdb
+  config:
+    shared_cache_config:
+      memory_limit: 34359738368
+    feature_flags: !inherit
+      enable_views: true
+    actor_system_config:
+      use_auto_config: true
+      node_type: COMPUTE
+      cpu_count: 14
+```
 
-### Updating dynamic configuration
+## Updating the dynamic configuration
 
 ```bash
 # Fetch the cluster configuration
@@ -98,9 +166,9 @@ vim dynconfig.yaml
 Additional configuration options are described on the [selectors](./dynamic-config-selectors.md) and [temporary configuration](./dynamic-config-volatile-config.md) pages.
 All commands for working with configuration are described in the [{#T}](../../reference/ydb-cli/configs.md) section.
 
-### Operation mechanism
+## Operation mechanism
 
-#### Configuration update from the administrator's perspective
+### Configuration update from the administrator's perspective
 
 1. The configuration file is uploaded by the user using a [grpc call](https://github.com/ydb-platform/ydb/blob/5251c9ace0a7617c25d50f1aa4d0f13e3d56f985/ydb/public/api/grpc/draft/ydb_dynamic_config_v1.proto#L22) or [{{ ydb-short-name }} CLI](../../reference/ydb-cli/index.md) to the cluster.
 2. The file is checked for validity, basic constraints, version correctness, cluster name correctness, and the correctness of the configurations obtained after DSL transformation are verified.
@@ -108,7 +176,7 @@ All commands for working with configuration are described in the [{#T}](../../re
 4. The file is reliably stored in the cluster using the Console [tablet](../../concepts/glossary.md#tablet).
 5. File updates are distributed across the cluster nodes.
 
-#### Configuration update from the cluster node's perspective
+### Configuration update from the cluster node's perspective
 
 1. Each node requests the entire configuration at startup.
 2. Upon receiving the configuration, the node [generates the final configuration](./dynamic-config-selectors.md#selectors-resolve) for its set of [labels](./dynamic-config-selectors.md#selectors-intro).
@@ -118,11 +186,11 @@ All commands for working with configuration are described in the [{#T}](../../re
 
 Steps 1 and 2 are performed only for dynamic cluster nodes.
 
-#### Configuration versioning
+### Configuration versioning
 
 This mechanism prevents concurrent configuration modifications and makes updates idempotent. When a modification request is received, the server compares the version of the received modification with the stored one. If the version is one less, the configurations are compared: if they are identical, it means the user is attempting to upload the configuration again, the user receives OK, and the cluster configuration is not updated. If the version matches the current one on the cluster, the configuration is replaced with the new one, and the version field is incremented by one. In all other cases, the user receives an error.
 
-### Dynamically updated settings {#dynamic-kinds}
+## Dynamically updated settings {#dynamic-kinds}
 
 Some system settings are updated without restarting nodes. To change them, upload a new configuration and wait for it to propagate across the cluster.
 
@@ -138,7 +206,7 @@ List of dynamically updated settings:
 
 The list may be expanded in the future.
 
-### Limitations
+## Limitations
 
 * Using more than 30 different [labels](./dynamic-config-selectors.md) in [selectors](./dynamic-config-selectors.md) can lead to validation delays of several seconds, as {{ ydb-short-name }} needs to check the validity of each possible final configuration. The number of values for a single label has much less impact.
-* Using large files (more than 500KiB for a cluster with 1000 nodes) can lead to increased network traffic in the cluster when updating the configuration. The traffic volume is directly proportional to the number of nodes and the configuration size.
\ No newline at end of file
+* Using large files (more than 500KiB for a cluster with 1000 nodes) can lead to increased network traffic in the cluster when updating the configuration. The traffic volume is directly proportional to the number of nodes and the configuration size.
diff --git a/ydb/docs/en/core/reference/configuration/index.md b/ydb/docs/en/core/reference/configuration/index.md
index b7dbeac8aae5..0f6d50bd1420 100644
--- a/ydb/docs/en/core/reference/configuration/index.md
+++ b/ydb/docs/en/core/reference/configuration/index.md
@@ -217,7 +217,23 @@ The [authentication mode](../../security/authentication.md) in the {{ ydb-short-
 domains_config:
   ...
   security_config:
-    enforce_user_token_requirement: Bool
+    # authentication mode settings
+    enforce_user_token_requirement: false
+    enforce_user_token_check_requirement: false
+    default_user_sids: <SID list for anonymous requests>
+    all_authenticated_users: <group SID for all authenticated users>
+    all_users_group: <group SID for all users>
+
+    # initial security settings
+    default_users: <initial list of users>
+    default_groups: <initial list of groups>
+    default_access: <initial permissions>
+
+    # настройки привилегий
+    viewer_allowed_sids: <list of SIDs enabled for YDB UI access>
+    monitoring_allowed_sids: <list of SIDs enabled for tablet administration>
+    administration_allowed_sids: <list of SIDs enabled for storage administration>
+    register_dynamic_node_allowed_sids: <list of SIDs enabled for database node registration>
   ...
 ```
 
diff --git a/ydb/docs/en/core/reference/configuration/node-authentication.md b/ydb/docs/en/core/reference/configuration/node-authentication.md
new file mode 100644
index 000000000000..6fc3030a89fd
--- /dev/null
+++ b/ydb/docs/en/core/reference/configuration/node-authentication.md
@@ -0,0 +1,73 @@
+# Database node authentication
+
+Database node authentication within the {{ ydb-short-name }} cluster ensures that service connections between cluster nodes are assigned the correct security identifiers, or [SIDs](../../concepts/glossary.md#access-sid). The process of database node authentication applies to connections that use the gRPC protocol and provide functions for registering nodes in the cluster, as well as for accessing configuration information. SIDs assigned to connections are considered when checking the authorization rules that apply to the corresponding gRPC service calls.
+
+Node authentication settings are configured within the [static configuration](./index.md) of the cluster.
+
+## client_certificate_authorization – node authentication settings
+
+This section specifies the authentication settings for database node connections by defining the requirements for the content of the "Subject" and "Subject Alternative Name" fields in node certificates, as well as the list of [SID](../../concepts/glossary.md#access-sid) values assigned to the connections.
+
+The "Subject" field of the node certificate may contain multiple components (such as `O` – organization, `OU` – organizational unit, `C` – country, `CN` – common name), and checks can be configured against one or more of these components.
+
+The "Subject Alternative Name" field of the node certificate is a list of the node's network names or IP addresses. Checks can be configured to match the names specified in the certificate against the expected values.
+
+### Syntax
+
+```yaml
+client_certificate_authorization:
+  request_client_certificate: Bool
+  default_group: <default SID>
+  client_certificate_definitions:
+    - member_groups: <SID array>
+      require_same_issuer: Bool
+      subject_dns:
+      - suffixes: <array of allowed suffixes>
+        values: <array of allowed values>
+      subject_terms:
+      - short_name: <Subject Name component>
+        suffixes: <array of allowed suffixes>
+        values: <array of allowed values>
+    - member_groups: <SID array>
+    ...
+```
+
+Key  | Description
+---- | ---
+`request_client_certificate` | Request a valid client certificate for node connections.<br/>Allowed values:<br/><ul><li>`false` — A certificate is not required (used by default if the parameter is omitted).</li><li>`true` — A certificate is required for all node connections.</li></ul>
+`default_group` | SID assigned to all connections providing a trusted client certificate when no explicit settings are provided in the `client_certificate_definitions` section.
+`client_certificate_definitions` | Section defining the requirements for database node certificates.
+`member_groups` | SIDs assigned to connections that conform to the requirements of the current configuration block.
+`require_same_issuer` | Require that the value of the "Issuer" field (typically containing the Certification Authority name) is the same for both client (database node) and server (storage node) certificates. <br/>Allowed values:<br/><ul><li>`true` — The values must be the same (used by default if the parameter is omitted).</li><li>`false` — The values can be different (allowing client and server certificates to be issued by different Certification Authorities).</li></ul>
+`subject_dns` | Allowed values for the "Subject Alternative Name" field, specified as either full values (using the `values` sub-key) or suffixes (using the `suffixes` sub-key). The check is successful if the actual value matches any full name or any suffix specified.
+`subject_terms` | Requirements for the "Subject" field value. Contains the component name (in the `short_name` sub-key) and a list of full values (using the `values` sub-key) or suffixes (using the `suffixes` sub-key). The check is successful if the actual value of each component matches either an allowed full value or an allowed suffix.
+
+### Examples
+
+The following configuration fragment enables node authentication and requires the "Subject" field to include the component `O=YDB`. Upon successful authentication, the connection is assigned the `registerNode@cert` SID.
+
+```yaml
+client_certificate_authorization:
+  request_client_certificate: true
+  client_certificate_definitions:
+    - member_groups: ["registerNode@cert"]
+      subject_terms:
+      - short_name: "O"
+        values: ["YDB"]
+```
+
+The next configuration fragment enables node authentication, and requires "Subject" field to include both `OU=cluster1` and `O=YDB` components. In addition "Subject Alternative Name" field should contain the network name ending with the `.cluster1.ydb.company.net` suffix. Upon successful authentication, the connection will be assigned the `registerNode@cert` SID.
+
+```yaml
+client_certificate_authorization:
+  request_client_certificate: true
+  client_certificate_definitions:
+    - member_groups: ["registerNode@cert"]
+      subject_dns:
+      - suffixes: [".cluster1.ydb.company.net"]
+      subject_terms:
+      - short_name: "OU"
+        values: ["cluster1"]
+      - short_name: "O"
+        values: ["YDB"]
+```
diff --git a/ydb/docs/en/core/reference/configuration/toc_p.yaml b/ydb/docs/en/core/reference/configuration/toc_p.yaml
index c26f18897f87..aae0fb18bedf 100644
--- a/ydb/docs/en/core/reference/configuration/toc_p.yaml
+++ b/ydb/docs/en/core/reference/configuration/toc_p.yaml
@@ -1,3 +1,5 @@
 items:
 - name: TLS
-  href: tls.md
\ No newline at end of file
+  href: tls.md
+- name: Database node authentication
+  href: node-authentication.md
diff --git a/ydb/docs/ru/core/devops/manual/node-authorization.md b/ydb/docs/ru/core/devops/manual/node-authorization.md
new file mode 100644
index 000000000000..e5a5a50b66d6
--- /dev/null
+++ b/ydb/docs/ru/core/devops/manual/node-authorization.md
@@ -0,0 +1,87 @@
+# Аутентификация и авторизация узлов баз данных
+
+Аутентификация узлов в кластере {{ ydb-short-name }} обеспечивает проверку подлинности узлов баз данных при выполнении служебных вызовов к другим узлам по протоколу gRPC. Авторизация узлов обеспечивает проверку и предоставление необходимых полномочий при обработке служебных вызовов, включая операции регистрации запускаемых узлов в кластере и доступа к [динамической конфигурации](../../maintenance/manual/dynamic-config.md). Использование аутентификации и авторизации узлов рекомендовано для всех кластеров {{ ydb-short-name }}, поскольку позволяет избежать ситуаций несанкционированного доступа к данным через включение в кластер контролируемых злоумышленниками узлов.
+
+Аутентификация и авторизация узлов баз данных осуществляется в следующем порядке:
+
+1. Запускаемый узел базы данных открывает gRPC-подключение к одному из узлов хранения кластера, указанных в опции командной строки `--node-broker`. При подключении используется протокол TLS, и в настройках подключения в качестве клиентского сертификата используется сертификат запускаемого узла.
+2. Узел хранения и узел базы данных осуществляют взаимные проверки подлинности с использованием протокола TLS: производится проверка цепочки доверия сертификата и проверка соответствия имени хоста значению поля "Subject Name" сертификата.
+3. Узел хранения проверяет заполнение поля "Subject" сертификата на соответствие  требованиям, устанавливаемым в статической конфигурации.
+4. При успешном прохождении перечисленных выше проверок подключение со стороны узла базы данных считается аутентифицированным, и ему присваивается специальный [SID](../../concepts/glossary.md#access-sid), определяемый настройками.
+5. Узел базы данных использует установленное gRPC-подключение для регистрации в составе кластера, а также для получения динамической конфигурации с использованием соответствующих служебных вызовов.
+6. Узел хранения проверяет наличие SID, присвоенного подключению, в списке допустимых. При успешном прохождении этой проверки узел хранения выполняет запрошенное действие.
+
+Далее описаны настройки, необходимые для включения функции аутентификации и авторизации узлов.
+
+## Пререквизиты для настройки
+
+1. В развернутом кластере {{ ydb-short-name }} должно быть [настроено шифрование трафика gRPC](../../reference/configuration/tls.md#grpc) с использованием протокола TLS.
+1. При подготовке сертификатов узлов для кластера, в котором планируется использовать функции аутентификации и авторизации узлов, необходимо обеспечить единые правила заполнения поля "Subject" сертификатов, позволяющие идентифицировать сертификаты, выпущенные для узлов кластера. Более подробная информация приведена в [документации по настройке правил проверки сертификатов](../../reference/configuration/node-authentication.md).
+
+    {% note info %}
+
+    Предлагаемый [пример скрипта](https://github.com/ydb-platform/ydb/blob/main/ydb/deploy/tls_cert_gen/) для генерации самоподписанных сертификатов узлов {{ ydb-short-name }} заполняет поле "Subject" значением `O=YDB` для всех сертификатов узлов. Приведённые далее примеры настроек подготовлены для сертификатов с именно таким заполнением поля "Subject".
+
+    {% endnote %}
+
+1. В параметры командной строки для [запуска узлов баз данных](../../devops/manual/initial-deployment.md#start-dynnode) необходимо добавить опции, задающие пути к файлам сертификатов доверенных центров сертификации, сертификата узла и ключа узла. Список дополнительных опций приведён в таблице ниже.
+
+    | **Опция командной строки** | **Описание** |
+    |----------------------------|--------------|
+    | `--grpc-ca`                | Путь к файлу сертификатов доверенных центров сертификации `ca.crt`. |
+    | `--grpc-cert`              | Путь к файлу сертификата узла `node.crt`. |
+    | `--grpc-key`               | Путь к файлу секретного ключа узла `node.key`. |
+
+    Пример команды для запуска узла базы данных с опциями, указывающими пути к ключам и сертификатам TLS для протокола gRPC:
+
+    ```bash
+    /opt/ydb/bin/ydbd server --yaml-config  /opt/ydb/cfg/config.yaml --tenant /Root/testdb \
+        --grpcs-port 2136 --grpc-ca /opt/ydb/certs/ca.crt \
+        --grpc-cert /opt/ydb/certs/node.crt --grpc-key /opt/ydb/certs/node.key \
+        --ic-port 19002 --ca /opt/ydb/certs/ca.crt \
+        --mon-port 8766 --mon-cert /opt/ydb/certs/web.pem \
+        --node-broker grpcs://<ydb1>:2135 \
+        --node-broker grpcs://<ydb2>:2135 \
+        --node-broker grpcs://<ydb3>:2135
+    ```
+
+## Включение режима аутентификации и авторизации узлов
+
+Для включения обязательной авторизации узлов баз данных в файл [статической конфигурации кластера](../../reference/configuration/index.md) необходимо добавить следующие блоки настроек:
+
+1. На корневом уровне конфигурации добавьте блок `client_certificate_authorization`, в котором укажите требования к заполнению поля "Subject" доверенных сертификатов подключаемых узлов, например:
+
+    ```yaml
+    client_certificate_authorization:
+      request_client_certificate: true
+      client_certificate_definitions:
+        - member_groups: ["registerNode@cert"]
+          subject_terms:
+          - short_name: "O"
+            values: ["YDB"]
+    ```
+
+    При необходимости добавьте другие проверки сертификатов [в соответствии с документацией](../../reference/configuration/node-authentication.md).
+
+    В случае успешной проверки сертификата и соответствия компонентов поля "Subject" сертификата требованиям, установленным в блоке `subject_terms`, подключению будут присвоены субъекты доступа, перечисленные в параметре `member_groups`. Чтобы отделить такие субъекты доступа от других групп и учётных записей, к их наименованию добавляется суффикс `@cert`.
+
+1. В блок настроек аутентификации кластера `security_config` добавьте элемент `register_dynamic_node_allowed_sids`, указав список субъектов доступа, которым разрешена регистрация узлов баз данных. По техническим причинам в этом списке также должен присутствовать субъект доступа `root@builtin`. Пример:
+
+    ```yaml
+    domains_config:
+        ...
+        security_config:
+            enforce_user_token_requirement: true
+            ...
+            register_dynamic_node_allowed_sids:
+            - "root@builtin" # требуется по техническим причинам
+            - "registerNode@cert"
+    ```
+
+    Более подробная информация по настройке параметров аутентификации кластера приведена в [соответствующем разделе документации](../../reference/configuration/index.md#security-access-levels).
+
+1. Обновите файлы статической конфигурации на всех узлах кластера вручную либо с помощью [плейбука Ansible](../ansible/update-config.md).
+
+1. Выполните поэтапный перезапуск узлов хранения кластера [с помощью ydbops](../../reference/ydbops/rolling-restart-scenario.md) либо с использованием [плейбука Ansible](../ansible/restart.md).
+
+1. Выполните поэтапный перезапуск узлов баз данных кластера с помощью ydbops либо с использованием плейбука Ansible.
diff --git a/ydb/docs/ru/core/devops/manual/toc_p.yaml b/ydb/docs/ru/core/devops/manual/toc_p.yaml
index c935391f83d8..861b74f19ec5 100644
--- a/ydb/docs/ru/core/devops/manual/toc_p.yaml
+++ b/ydb/docs/ru/core/devops/manual/toc_p.yaml
@@ -13,14 +13,14 @@ items:
   href: backup-and-recovery.md
 - name: Обновление
   href: upgrade.md
-- name: Изменение конфигурации актор-системы
-  href: ../../maintenance/manual/change_actorsystem_configs.md
 - name: Управление конфигурацией кластера
   items:
   - name: Обзор конфигурации
     href: ../../maintenance/manual/config-overview.md
   - name: Статическая конфигурация кластера
     href: ../../reference/configuration/index.md
+  - name: Аутентификация и авторизация узлов баз данных
+    href: node-authorization.md
   - name: Динамическая конфигурация кластера
     href: ../../maintenance/manual/dynamic-config.md
   - name: DSL конфигурации кластера
@@ -29,6 +29,8 @@ items:
     href: ../../maintenance/manual/dynamic-config-volatile-config.md
   - name: Изменение конфигураций через CMS
     href: ../../maintenance/manual/cms.md
+  - name: Изменение конфигурации актор-системы
+    href: ../../maintenance/manual/change_actorsystem_configs.md
 - name: Системные представления
   href: system-views.md
 - name: Обслуживание без потери доступности
diff --git a/ydb/docs/ru/core/maintenance/manual/dynamic-config.md b/ydb/docs/ru/core/maintenance/manual/dynamic-config.md
index f3510ac19dde..f32b687443b6 100644
--- a/ydb/docs/ru/core/maintenance/manual/dynamic-config.md
+++ b/ydb/docs/ru/core/maintenance/manual/dynamic-config.md
@@ -1,4 +1,4 @@
-## Динамическая конфигурация кластера
+# Динамическая конфигурация кластера
 
 Динамическая конфигурация позволяет запускать динамические [узлы](../../concepts/glossary.md#node), сконфигурировав их централизованно, без необходимости раскладывать файлы по узлам вручную. {{ ydb-short-name }} выступает в роли системы управления конфигурациями, предоставляя инструменты для надёжного хранения, версионирования и доставки конфигурации, а так же [DSL (Domain Specific Language)](./dynamic-config-selectors.md) для переопределения её частей для определённых групп узлов. Конфигурация представляет собой YAML документ. Он является расширенной версией статической конфигурации:
 
@@ -6,14 +6,49 @@
 * добавлено поле `metadata`, необходимое для валидации и версионирования;
 * добавлены поля `allowed_labels` и `selector_config` для гранулярного переопределения настроек.
 
-Эта конфигурация загружается в кластер, где надёжно сохраняется и доставляется до каждого динамического узла при его старте. [Определенные настройки](#dynamic-kinds) обновляются на лету, без перезапуска узлов. С помощью динамической конфигурации можно централизованно решить следующие задачи:
+Эта конфигурация загружается в кластер, где надёжно сохраняется и доставляется до каждого динамического узла при его старте. [Некоторые настройки](#dynamic-kinds) обновляются на лету, без перезапуска узлов. С помощью динамической конфигурации можно централизованно решить следующие задачи:
 
-* переключение настроек журналирования компонентов как для всего кластера, так и для отдельных групп узлов;
-* включать экспериментальную функциональность (feature flags) на отдельных базах;
-* изменить настройки акторной системы на отдельно узле или на групе узлов;
-* и т.д.
+* переключать настройки журналирования компонентов как для всего кластера, так и для отдельных баз данных или групп узлов;
+* включать экспериментальную функциональность (feature flags) на отдельных базах данных;
+* изменять настройки акторной системы на конкретной базе данных, отдельном узле или на группе узлов.
 
-### Примеры конфигурации {#example}
+## Подготовка к использованию динамической конфигурации {#preparation}
+
+Перед началом использования динамической конфигурации в кластере необходимо провести подготовительные работы:
+
+1. Включите в кластере [аутентификацию и авторизацию узлов баз данных](../../devops/manual/node-authorization.md).
+
+1. Если ранее в кластере использовалось [управление конфигурацией через CMS](cms.md), выгрузите существующие настройки в формате YAML. Для этого выполните следующую команду:
+
+    ```bash
+    ./ydbd -s grpcs://<node1.ydb.tech>:2135 --ca-file ca.crt --token-file ydbd-token \
+         admin console configs dump-yaml > dynconfig.yaml
+    ```
+
+    Предварительно необходимо получить токен аутентификации с помощью команды `ydb auth get-token`, аналогично [процедуре инициализации кластера](../../devops/manual/initial-deployment.md#initialize-cluster).
+
+1. Сформируйте первоначальный файл динамической конфигурации:
+
+   * Если ранее в CMS выполнялись настройки (экспортированные на предыдущем шаге), используйте полученный файл в качестве основы и:
+      * добавьте секцию `metadata` по образцу из [примера конфигурации](#example);
+      * в секцию `config` добавьте параметр `yaml_config_enabled: true`.
+   * Если ранее настройки через CMS не выполнялись, используйте [минимальное наполнение](#example) файла динамической конфигурации.
+   * Если в кластере используется шифрование [интерконнекта акторной системы](../../concepts/glossary.md#actor-system-interconnect), добавьте в секцию `config` соответствующие [настройки TLS для интерконнекта](../../reference/configuration/tls.md#interconnect).
+
+1. Примените сформированный файл динамической конфигурации на кластер:
+
+    ```bash
+    # Применить конфигурационный файл dynconfig.yaml на кластер
+    {{ ydb-cli }} admin config replace -f dynconfig.yaml
+    ```
+
+{% note info %}
+
+После включения поддержки динамической конфигурации в кластере {{ ydb-short-name }} устаревшая функция управления конфигурацией через CMS станет недоступной.
+
+{% endnote %}
+
+## Примеры конфигурации {#example}
 
 Пример минимальной динамической конфигурации для однодатацентрового кластера:
 
@@ -22,69 +57,102 @@
 # Поле управляется сервером
 metadata:
   # Имя кластера из параметра cluster_uuid, выставляемом при установке кластера, или "", если параметр не выставлен
-  cluster: unknown
-  # Идентификатор конфигурационного файла, всегда возрастает на 1 и начинается с 1.
+  cluster: ""
+  # Идентификатор конфигурационного файла, всегда возрастает на 1 и начинается с 0.
   # Увеличивается автоматически при загрузке новой конфигурации на сервер.
-  version: 1
+  version: 0
 # Основная конфигурация кластера, все значения из него применяются по-умолчанию, пока не переопределены селекторами.
 # Содержание аналогично статической конфигурации кластера
 config:
-# должен быть всегда выставлен в true для использования yaml конфигурации
+  # должен быть всегда выставлен в true для использования yaml конфигурации
   yaml_config_enabled: true
-# конфигурация актор-системы, т.к. по-умолчанию данная секция используется только дин-нодами
-# выставлена конфигурация именно для ни
+  # конфигурация актор-системы - поскольку по-умолчанию данная секция используется
+  # только узлами БД, выставлена конфигурация именно для них
   actor_system_config:
-# автоматический подбор конфигурации для ноды на основе типа и количества доступных ядер
+    # автоматический подбор конфигурации для ноды на основе типа и количества доступных ядер
     use_auto_config: true
-# HYBRID || COMPUTE || STORAGE — тип ноды
+    # HYBRID || COMPUTE || STORAGE — тип ноды, для узлов баз данных всегда COMPUTE
     node_type: COMPUTE
-# число ядер
-    cpu_count: 4
-# конфигурация корневого домена кластера {{ ydb-short-name }}
-  domains_config:
-    domain:
-    - name: Root
-      storage_pool_types:
-      - kind: ssd
-        pool_config:
-          box_id: 1
-          erasure_species: none
-          kind: ssd
-          pdisk_filter:
-          - property:
-            - type: SSD
-          vdisk_kind: Default
-      explicit_mediators: [72075186232426497, 72075186232426498, 72075186232426499]
-      explicit_coordinators: [72075186232360961, 72075186232360962, 72075186232360963]
-      explicit_allocators: [72075186232492033, 72075186232492034, 72075186232492035]
-    state_storage:
-    - ssid: 1
-      ring:
-        nto_select: 5
-        node: [1, 2, 3, 4, 5, 6, 7, 8]
-    hive_config:
-    - hive_uid: 1
-      hive: 72057594037968897
-# конфигурация профилей каналов таблеток
-  channel_profile_config:
-    profile:
-    - profile_id: 0
-      channel:
-      - &default_channel
-        erasure_species: block-4-2
-        pdisk_category: 1
-        vdisk_category: Default
-      - *default_channel
-      - *default_channel
+    # количество выделенных ядер
+    cpu_count: 14
 allowed_labels: {}
 selector_config: []
 ```
 
 Подробнее параметры конфигурации описаны на странице [{#T}](../../reference/configuration/index.md).
 
-По умолчанию конфигурация кластера является пустой и имеет версию 1. При применении новой конфигурации версия загружаемой конфигурации сравнивается и автоматически увеличивается на единицу.
+Первоначально установленная динамическая конфигурация кластера получает номер версии 1. При применении новой конфигурации версия хранимой конфигурации сравнивается с указанной в YAML-документе и автоматически увеличивается на единицу.
+
+Пример более сложной динамической конфигурации с установкой типовых глобальных параметров, а также особых параметров для одной из баз данных:
+
+```yaml
+---
+metadata:
+  kind: MainConfig
+  cluster: ""
+  version: 1
+config:
+  yaml_config_enabled: true
+  table_profiles_config:
+    table_profiles:
+    - name: default
+      compaction_policy: default
+      execution_policy: default
+      partitioning_policy: default
+      storage_policy: default
+      replication_policy: default
+      caching_policy: default
+    compaction_policies:
+    - name: default
+    execution_policies:
+    - name: default
+    partitioning_policies:
+    - name: default
+      auto_split: true
+      auto_merge: true
+      size_to_split: 2147483648
+    storage_policies:
+    - name: default
+      column_families:
+      - storage_config:
+          sys_log:
+            preferred_pool_kind: ssd
+          log:
+            preferred_pool_kind: ssd
+          data:
+            preferred_pool_kind: ssd
+    replication_policies:
+    - name: default
+    caching_policies:
+    - name: default
+  interconnect_config:
+    encryption_mode: REQUIRED
+    path_to_certificate_file: "/opt/ydb/certs/node.crt"
+    path_to_private_key_file: "/opt/ydb/certs/node.key"
+    path_to_ca_file: "/opt/ydb/certs/ca.crt"
+allowed_labels:
+  node_id:
+    type: string
+  host:
+    type: string
+  tenant:
+    type: string
+selector_config:
+- description: Custom settings for testdb
+  selector:
+    tenant: /cluster1/testdb
+  config:
+    shared_cache_config:
+      memory_limit: 34359738368
+    feature_flags: !inherit
+      enable_views: true
+    actor_system_config:
+      use_auto_config: true
+      node_type: COMPUTE
+      cpu_count: 14
+```
 
-### Обновление динамической конфигурации
+## Обновление динамической конфигурации
 
 ```bash
 # Получить конфигурацию кластера
@@ -98,9 +166,9 @@ vim dynconfig.yaml
 Дополнительные возможности конфигурирования описаны на страницах [селекторы](./dynamic-config-selectors.md) и [временная конфигурация](./dynamic-config-volatile-config.md).
 Все команды для работы с конфигурацией описаны в разделе [{#T}](../../reference/ydb-cli/configs.md).
 
-### Механизм работы
+## Механизм работы
 
-#### Обновление конфигурации c точки зрения администратора
+### Обновление конфигурации c точки зрения администратора
 
 1. Конфигурационный файл загружается пользователем при помощи [grpc-вызова](https://github.com/ydb-platform/ydb/blob/5251c9ace0a7617c25d50f1aa4d0f13e3d56f985/ydb/public/api/grpc/draft/ydb_dynamic_config_v1.proto#L22) или [{{ ydb-short-name }} CLI](../../reference/ydb-cli/index.md) в кластер.
 2. Файл проверяется на валидность, проверяются базовые ограничения, корректность версии, корректность имени кластера, корректность конфигураций полученных после преобразования DSL.
@@ -108,7 +176,7 @@ vim dynconfig.yaml
 4. Файл надёжно сохраняется в кластере [таблеткой](../../concepts/glossary.md#tablet) Console.
 5. Обновления файла рассылаются по узлам кластера.
 
-#### Обновление конфигурации с точки зрения узла кластера
+### Обновление конфигурации с точки зрения узла кластера
 
 1. Каждый узел при старте запрашивает полную конфигурацию.
 2. Получив конфигурацию, узел [генерирует конечную конфигурацию](./dynamic-config-selectors.md#selectors-resolve) для своего набора [лейблов](./dynamic-config-selectors.md#selectors-intro).
@@ -118,11 +186,11 @@ vim dynconfig.yaml
 
 Пункты 1,2 выполняются только для динамических узлов кластера.
 
-#### Версионирование конфигурации
+### Версионирование конфигурации
 
 Данный механизм позволяет избежать конкурентной модификации конфигурации и сделать её обновление идемпотентным. При получении запроса на модификацию конфигурации сервер сравнивает версию полученной модификации с сохраненной. Если версия меньше на единицу, то конфигурации сравниваются — если они одинаковы, значит пользователь пытается загрузить конфигурацию повторно, пользователь получает ОК, а конфигурация на кластере не обновляется. Если версия равна текущей на кластере, то конфигурация заменяется на новую, при этом поле версии увеличивается на единицу. Во всех остальных случаях пользователь получает ошибку.
 
-### Динамически обновляемые настройки {#dynamic-kinds}
+## Динамически обновляемые настройки {#dynamic-kinds}
 
 Часть настроек системы обновляется без перезапуска узлов. Для их изменения достаточно загрузить новую конфигурацию и дождаться её распространения по кластеру.
 
@@ -138,7 +206,7 @@ vim dynconfig.yaml
 
 В будущем список может быть расширен.
 
-### Ограничения
+## Ограничения
 
 * Использование более 30 различных [лейблов](./dynamic-config-selectors.md) в [селекторах](./dynamic-config-selectors.md) может привести к задержкам при валидации конфигурации в десятки секунд, т.к. {{ ydb-short-name }} необходимо проверить валидность каждой возможной конечной конфигурации. При этом количество значений одного лейбла влияет намного меньше.
-* Использование объемных файлов (более 500KiB для кластера в 1000 узлов), конфигурации может привести к росту сетевого трафика в кластере при обновлении конфигурации. Объем трафика прямо пропорционален количеству нод и объему конфигурации.
+* Использование объемных файлов (более 500KiB для кластера в 1000 узлов) конфигурации может привести к росту сетевого трафика в кластере при обновлении конфигурации. Объем трафика прямо пропорционален количеству нод и объему конфигурации.
diff --git a/ydb/docs/ru/core/reference/configuration/index.md b/ydb/docs/ru/core/reference/configuration/index.md
index fa4b410d6a12..b0ca53143930 100644
--- a/ydb/docs/ru/core/reference/configuration/index.md
+++ b/ydb/docs/ru/core/reference/configuration/index.md
@@ -260,10 +260,9 @@ domains_config:
     viewer_allowed_sids: <список SID'ов с правами просмотра состояния кластера>
     monitoring_allowed_sids: <список SID'ов с правами просмотра и изменения состояния кластера>
     administration_allowed_sids: <список SID'ов с доступом администратора кластера>
+    register_dynamic_node_allowed_sids: <список SID'ов с правами регистрации узлов баз данных в кластере>
 ```
 
-[//]: # (TODO: wait for pull/9387, dynamic_node_registration to add info about "register_dynamic_node_allowed_sids: <список SID'ов с правами подключения динамических нод в кластер>")
-
 #### Настройки режима аутентификации {#security-auth}
 
 #|
@@ -418,9 +417,11 @@ default_access:
 
 Даёт право на выполнение административных действий с базами или кластером.
     ||
-|#
+|| `register_dynamic_node_allowed_sids` | Список [SID](../../concepts/glossary.md#access-sid)'ов , для которых разрешена регистрация узлов баз данных.
 
-[//]: # (TODO: wait for pull/9387, dinamic_node_registration to add info about `register_dynamic_node_allowed_sids`)
+По техническим причинам в этом списке также должен присутствовать субъект доступа `root@builtin`.
+    ||
+|#
 
 {% note warning %}
 
diff --git a/ydb/docs/ru/core/reference/configuration/node-authentication.md b/ydb/docs/ru/core/reference/configuration/node-authentication.md
new file mode 100644
index 000000000000..f31996371798
--- /dev/null
+++ b/ydb/docs/ru/core/reference/configuration/node-authentication.md
@@ -0,0 +1,73 @@
+# Аутентификация узлов баз данных
+
+Аутентификация узлов баз данных в кластере {{ ydb-short-name }} обеспечивает присвоение служебным подключениям между узлами кластера корректных идентификаторов защиты, или [SID](../../concepts/glossary.md#access-sid). Процесс аутентификации узлов баз данных относится к подключениям, использующим протокол gRPC и обеспечивающим выполнение функций регистрации узлов в кластере, а также доступа к конфигурационной информации. Присвоенные подключениям SID учитываются при проверке правил авторизации, действующих в отношении служебных gRPC-вызовов.
+
+Настройки аутентификации узлов баз данных указываются в составе [статической конфигурации](./index.md) кластера.
+
+## client_certificate_authorization — настройки аутентификации узлов
+
+Этот раздел конфигурации управляет режимом аутентификации при подключении узлов баз данных и определяет требования к заполнению полей "Subject" и "Subject Alternative Name" сертификатов узлов, а также список присваиваемых идентификаторов защиты [SID](../../concepts/glossary.md#access-sid).
+
+Поле "Subject" сертификата узла состоит из нескольких компонентов (например, `O` — организация, `OU` — подразделение в составе организации, `C` — страна, `CN` — имя собственное субъекта). Проверки могут быть настроены на соответствие одного или нескольких компонентов поля ожидаемым значениям.
+
+Поле "Subject Alternative Name" сертификата узла представляет собой список сетевых имён или IP-адресов узлов. Проверка может быть настроена на соответствие сетевых имён в сертификате ожидаемым значениям.
+
+### Синтаксис
+
+```yaml
+client_certificate_authorization:
+  request_client_certificate: Bool
+  default_group: <SID по умолчанию>
+  client_certificate_definitions:
+    - member_groups: <массив SID>
+      require_same_issuer: Bool
+      subject_dns:
+      - suffixes: <массив разрешенных суффиксов>
+        values: <массив допустимых значений>
+      subject_terms:
+      - short_name: <имя компонента Subject Name>
+        suffixes: <массив разрешенных суффиксов>
+        values: <массив допустимых значений>
+    - member_groups: <массив SID>
+    ...
+```
+
+Ключ | Описание
+---- | ---
+`request_client_certificate` | Требовать корректный клиентский сертификат для подключения узлов.<br/>Допустимые значения:<br/><ul><li>`false` — сертификат не требуется (применяется по умолчанию, если параметр не задан);</li><li>`true` — для подключения узлов требуется доверенный клиентский сертификат.</li></ul>
+`default_group` | SID, присваиваемый всем подключениям с доверенным клиентским сертификатом, если нет явно заданных настроек в секции `client_certificate_definitions`.
+`client_certificate_definitions` | Блок настроек требований к сертификатам узлов баз данных.
+`member_groups` | Массив SID, присваиваемых подключениям, сертификаты которых соответствуют требованиям этого блока.
+`require_same_issuer` | Требовать совпадение поля "Issuer" (наименование центра регистрации) для клиентского (узел базы данных) и серверного (узел хранения) сертификатов.<br/>Допустимые значения:<br/><ul><li>`true` — совпадение требуется (применяется по умолчанию, если параметр не задан);</li><li>`false` — совпадение не требуется (клиентский и серверный сертификаты могут быть выпущены разными центрами регистрации).</li></ul>
+`subject_dns` | Допустимые значения поля "Subject Alternative Name" в виде массива полных значений (ключ `values`) или массива суффиксов значений (ключ `suffixes`). Проверка считается успешной при совпадении одного из значений поля с любым полным именем либо при соответствии любому указанному суффиксу.
+`subject_terms` | Требования к заполнению компонентов поля "Subject". Указывается имя компонента (ключ `short_name`), а также набор полных значений (ключ `values`) или набор суффиксов значений (ключ `suffixes`). Проверка считается успешной, если для каждого проверяемого компонента поля "Subject" его значение соответствует одному из разрешённых полных значений либо одному из разрешённых суффиксов.
+
+### Примеры
+
+Следующий фрагмент конфигурации включает аутентификацию узлов и требует наличия в поле "Subject" компонента `O=YDB`. При успешной аутентификации подключению будет присвоен субъект доступа `registerNode@cert`.
+
+```yaml
+client_certificate_authorization:
+  request_client_certificate: true
+  client_certificate_definitions:
+    - member_groups: ["registerNode@cert"]
+      subject_terms:
+      - short_name: "O"
+        values: ["YDB"]
+```
+
+Следующий фрагмент конфигурации включает аутентификацию узлов и требует наличия в поле "Subject" компонентов `OU=cluster1` и `O=YDB`. Дополнительно проверяется, что поле "Subject Alternative Name" содержит имя хоста, заканчивающееся на суффикс `.cluster1.ydb.company.net`. При успешной аутентификации подключению будет присвоен субъект доступа `registerNode@cert`.
+
+```yaml
+client_certificate_authorization:
+  request_client_certificate: true
+  client_certificate_definitions:
+    - member_groups: ["registerNode@cert"]
+      subject_dns:
+      - suffixes: [".cluster1.ydb.company.net"]
+      subject_terms:
+      - short_name: "OU"
+        values: ["cluster1"]
+      - short_name: "O"
+        values: ["YDB"]
+```
diff --git a/ydb/docs/ru/core/reference/configuration/toc_p.yaml b/ydb/docs/ru/core/reference/configuration/toc_p.yaml
index c26f18897f87..ce2bfc5a67ab 100644
--- a/ydb/docs/ru/core/reference/configuration/toc_p.yaml
+++ b/ydb/docs/ru/core/reference/configuration/toc_p.yaml
@@ -1,3 +1,5 @@
 items:
-- name: TLS
-  href: tls.md
\ No newline at end of file
+- name: Настройка TLS
+  href: tls.md
+- name: Аутентификация узлов баз данных
+  href: node-authentication.md