---
title: "Identity & Access Management"
sidebar_position: 4
description: "How to manage access to products, services, and cloud platform tools"
toc_max_heading_level: 3
---

import Tabs from '@theme/Tabs'
import TabItem from '@theme/TabItem'
import { TabItemLabel } from 'docs-kit/components'
import Formbricks from '@theme/MDXComponents/Formbricks'

# Identity & Access Management

## Control panel \{#access-to-control-panel}

In Selectel, you can manage user access to the infrastructure. This is accomplished by using Identity and Access Management (IAM), which checks every request and ensures that only authorized users perform operations on resources.

Access rights to resources are set at the level of [user types and roles](/access-control/access-management.mdx). Only the [Account Owner](/access-control/user-types.mdx#account-owner) or users with the [`iam_admin`](/access-control/role-reference.mdx#iam-admin) role can [add users](/access-control/manage/add-user.mdx) and [edit their data and roles](/access-control/manage/edit-user-data-or-role.mdx). To simplify user management, you can group them into [groups](/access-control/groups/).

By default, two-factor authentication is enabled for all users after registration and profile completion [two-factor authentication](/account/two-step-authentication.mdx). With two-factor authentication, you need to enter your password and a one-time confirmation code to log in to your account. The confirmation code can be received through an authenticator app or via the email address specified in your profile. Two-factor authentication can only be disabled by the Account Owner. We do not recommend disabling two-factor authentication to avoid risks associated with account compromise.

You can also set up authentication in the control panel using Single Sign-On (SSO) technology. To do this, use [identity federations](/access-control/federations/about-federations.mdx) — a centralized service for managing organizational structure, setting up integration with an employee directory, and controlling user access to company resources. When using a federation, user data is stored with your identity provider (e.g., Keycloak, ADFS, or other SAML-compliant providers).

By default, access to the control panel is allowed from any IP address. However, the Account Owner and a user with the [`iam.admin`](/access-control/role-reference.mdx#iam-admin) role can set restrictions: users will only be able to log in to the account from IP addresses and subnets that have been [added to the allowlist](/account/limit-access-to-account.mdx#add-address).

If you need to share access to the control panel or resources with someone, do not share your credentials. The Account Owner and a user with the [`iam.admin`](/access-control/role-reference.mdx#iam-admin) role can create an additional user for control panel access or a service user for programmatic access; for more details, see the article [Access management in Selectel products](/access-control/access-management.mdx).

## Cloud and dedicated servers \{#cloud-and-dedicated-servers}

You can [connect to cloud servers via the console in the control panel](/cloud-servers/manage/connect-to-server.mdx), and to dedicated servers — via the [KVM console](/dedicated/manage/kvm-console.mdx). If you are connecting to a server via other CLIs, to ensure secure remote access to the infrastructure, connect to the server:

* via [the SSH protocol](#configure-ssh-connection) — if you have a server with Linux OS;
* or via [the RDP protocol](#recommendations-for-rdp) — if you have a server with Windows OS.

### Configure SSH connection \{#configure-ssh-connection}

For secure [connection to a cloud](/cloud-servers/manage/connect-to-server.mdx) or [dedicated](/dedicated/manage/connect-to-server.mdx) server with a Linux OS, use SSH keys instead of a login and password. This is a key pair: a private key and a public key. The private key is stored on the local computer, and the public key is placed on the server. After configuring the SSH connection and disabling password access, only devices that store the private key will be able to connect to the server, and the server will be protected against brute-force attacks (bruteforce).

For each administrator, you need to [create an SSH key pair and place the public key on a cloud](/cloud-servers/manage/create-and-place-ssh-key.mdx) or [dedicated server](/dedicated/manage/create-and-place-ssh-key.mdx). When creating a key, specify a passphrase (passphrase) for additional protection.

After creating SSH keys, create a user and configure the SSH connection — when creating a server using [user data](/cloud-servers/manage/user-data.mdx) or for a created server via CLI. If you are using servers with a public IP address, the safest strategy is to configure security settings at the server creation stage using user data.

<Tabs>
  <TabItem value="userdata" default>
    <TabItemLabel>User data</TabItemLabel>

    You can [specify user data for a cloud](/cloud-servers/manage/user-data.mdx) and [dedicated server](/dedicated/manage/user-data.mdx#enter-user-data).

    Example of creating a user and configuring an SSH connection using user data for Ubuntu 24.04 LTS 64-bit.

    ```bash
    #cloud-config
    users:
    - name: admin
        sudo: ['ALL=(ALL) NOPASSWD:ALL']
        groups: sudo
        shell: /bin/bash
        lock_passwd: true
        ssh_authorized_keys:
        - <<public_ssh_key> admin@test
    ssh_pwauth: false

    package_update: true

    packages:
    - ufw

    runcmd:
    - sed -i 's/^#Port 22/Port 2222/' /etc/ssh/sshd_config
    - sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
    - sed -i 's/^PermitRootLogin prohibit-password/PermitRootLogin no/' /etc/ssh/sshd_config
    - sed -i 's/^#PubkeyAuthentication yes/PubkeyAuthentication yes/' /etc/ssh/sshd_config
    - systemctl restart ssh
    - ufw allow 2222/tcp
    - ufw --force enable
    - reboot
    ```

    Where:

    * `name: admin` — creates a user called `admin`;
    * `sudo: ['ALL=(ALL) NOPASSWD:ALL']` — allows the user to run commands via `sudo` without a password prompt;
    * `groups: sudo` — adds the user to the `sudo`` group`;
    * `lock_passwd: true` — locks password login for the `admin`` user`;
    * `<public_ssh_key> admin@test` in the `ssh_authorized_keys` section — adds the public SSH key you created earlier. It starts with `ssh-rsa`.
    * `ssh_pwauth: false` — disables password login for all users. Access to the server will be possible only via SSH key, and password login will be completely disabled;
    * `package_update: true ` — updates the apt library;
    * `packages: ufw` — installs the UFW (Uncomplicated Firewall), which is required to restrict access to the SSH port;
    * commands with `sed -i` in the `runcmd` section — change the default port `22` to `2222`, disable password login and root user connection, and enable key-based authentication.
  </TabItem>

  <TabItem value="cli">
    <TabItemLabel>CLI</TabItemLabel>

    Configuration example for a Linux OS with the Uncomplicated Firewall (UFW) installed.

    1. Open the CLI.

    2. Create an `admin:` user:

       ```bash
       sudo useradd -m -G sudo -s /bin/bash admin
       ```

    3. Create the `.ssh` directory in the home directory of the created user and go into it:

       ```bash
       mkdir /home/admin/.ssh
       cd /home/admin/.ssh
       ```

    4. Create the `authorized_keys:` file:

       ```bash
       touch authorized_keys
       ```

    5. Add the public SSH key to the `authorized_keys` file:

       ```bash
       echo <public_ssh_key> >> /home/admin/.ssh/authorized_keys
       ```

       Specify `<public_ssh_key>` — the public SSH key you created earlier. It starts with `ssh-rsa`.

    6. Configure access rights:

       ```bash
       chown admin:admin /home/admin/.ssh
       chown admin:admin /home/admin/.ssh/authorized_keys
       chmod 700 /home/admin/.ssh
       chmod 600 /home/admin/.ssh/authorized_keys
       ```

    7. In the `/etc/ssh/sshd_config` file, configure the SSH connection and disable password access:

       ```bash
       vi /etc/ssh/sshd_config
       PasswordAuthentication no
       PubkeyAuthentication yes
       PermitRootLogin no
       Port 2222
       ```

       Where:

       * `PasswordAuthentication no` — disables password authentication;
       * `PubkeyAuthentication yes` — enables key-based authentication;
       * `PermitRootLogin no` — denies SSH access for the root user;
       * `Port 2222` — changes the default SSH port `22` to port `2222`.

    8. Restart the SSH service for the changes to take effect:

       ```bash
       systemctl restart ssh
       ```

    9. For the Uncomplicated Firewall (UFW), add a rule that allows the new port to be used for SSH connections:

       ```bash
       ufw allow 2222/tcp
       ```

    10. Start the firewall, enable automatic firewall startup, and apply all rules — for example, for the UFW firewall:

        ```bash
        ufw --force enable
        ```

    11. Restart the server.
  </TabItem>
</Tabs>

### Recommendations for using RDP connections \{#recommendations-for-rdp}

To securely [connect via RDP to a cloud](/cloud-servers/manage/connect-to-server.mdx#connect-via-rdp) or [dedicated server](/dedicated/manage/connect-to-server.mdx#connect-via-rdp) with Windows OS, do not use a public IP address. We recommend using a VPN for access to such servers — for example, OpenVPN, WireGuard, or IKEv2/IPsec. To do this, place [cloud](/cloud-servers/cloud-networks/private-networks-and-subnets.mdx) and [dedicated servers](/dedicated/networks/about-networks.mdx) in private subnets that are accessible via a separate VPN gateway, or deploy a VPN gateway on the same server.

Use a separate account for each server administrator.

### Additional security tools \{#additional-security-tools}

To protect servers from unauthorized access, we recommend using additional security tools. Examples of free tools:

* [Fail2Ban](https://github.com/fail2ban/fail2ban);
* [Penalties in OpenSSH](https://man.openbsd.org/sshd_config#PerSourcePenalties);
* [CrowdSec](https://github.com/crowdsecurity/crowdsec).

### Certified security features \{#certified-security-features}

To provide additional server protection, as well as to comply with legal requirements where necessary, you can use additional certified security tools against unauthorized access, which are provided as a separate service:

* [Secret Net LSP (Linux)](/certified-security-features/secret-net-lsp.mdx);
* [Secret Net Studio (Windows)](/certified-security-features/secret-net-studio.mdx);
* [Dallas Lock Trusted Boot Tool](/certified-security-features/dallas-lock.mdx).

### Two-factor authentication \{#2fa}

To protect your services from unauthorized access, we recommend using [two-factor authentication](/2fa/about-2fa.mdx) for additional user identity verification. The service is provided via licenses for the [Multifactor solution](https://multifactor.ru/).

The Multifactor solution complies with regulatory requirements:

* is included in the Unified Register of Russian Software (No. 7046);
* complies with the international PCI DSS standard;
* has an FSTEC certificate (No. 5039).

## Managed Kubernetes \{#managed-kubernetes}

In a Managed Kubernetes cluster, you can control access to virtual resources using the RBAC Authorization mechanism (RBAC). RBAC allows you to [assign user roles](/managed-kubernetes/clusters/rbac-authorization.mdx#assign-user-roles) — create different namespaces for different applications and configure user access to pods in the corresponding namespace.

## Managed databases \{#managed-databases}

In all DBMS, except Redis, you can manage database users and their privileges. More information about user management is available in the instructions for [PostgreSQL](/managed-databases/postgresql/manage-users.mdx), [PostgreSQL for 1C](/managed-databases/postgresql-for-1c/manage-users-1c.mdx), [PostgreSQL TimescaleDB](/managed-databases/timescaledb/manage-users.mdx), [MySQL semi-sync](/managed-databases/mysql-semi-sync/manage-users.mdx), [MySQL sync](/managed-databases/mysql-sync/manage-users.mdx) and [Kafka](/managed-databases/kafka/manage-users.mdx).

For the Redis DBMS, one user is created automatically. The password for this user is set when creating the cluster, and it can be [changed](/managed-databases/redis/change-password.mdx) after the cluster is created.

## S3 \{#access-to-s3}

Access to S3 resources is regulated by:

* [a role model](/s3/manage/manage-access.mdx#access-within-roles) — determines access within an account and [project](/access-control/projects/about-projects.mdx);
* [bucket policy](/s3/manage/manage-access.mdx#access-within-bucket-policy) — defines access within a bucket.

When an action request is received in S3, access is first checked according to the role model. If the role model allows access, the access policy is checked; if not, access is denied. With the access policy, anything not allowed by the policy rules is denied.

To grant access via API or FTP, [issue keys](/s3/manage/manage-access.mdx#keys-for-api-access).

To access objects in a bucket via your own domain over HTTPS, you must [add a TLS (SSL) certificate](/s3/manage/tls-ssl-certificates.mdx#add-certificate). You can issue a certificate from any provider. You can manage certificates via the [control panel](https://my.selectel.ru/) or [Object Storage API](/api/object-storage/).

<Formbricks />