Identity & Access Management

Last update: May 30 2026

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.

User access permissions for resources are set at the level of user types and roles. Only the Account Owner or users with the iam_admin role can add users and edit their data and roles. To simplify user management, you can combine them into groups.

By default, two-factor authentication is enabled for all users after registration and profile completion. Two-factor authentication requires entering a password and a one-time confirmation code to log in to your account. The confirmation code can be received through the authenticator app or by email to the address you 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 configure authentication in the control panel using Single Sign-On (SSO) technology. To do this, use identity federations — a centralized service for managing organizational structure, setting up integration with the employee directory, and controlling user access to company resources. When using federations, user data is stored with your identity provider (e.g., Keycloak, ADFS, and 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 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.

If you need to share access to the control panel or resources with someone else, do not share your own credentials. The Account Owner and a user with the iam.admin role can create an additional user for control panel access or a service user for programmatic access; see the instruction Access management in Selectel products.

Cloud and dedicated servers

You can connect to cloud servers via the console in the control panel, and to dedicated servers — via the KVM console. If you are connecting to a server using other CLIs, to ensure secure remote access to the infrastructure, connect to the server:

• via the SSH protocol — if you have a server with Linux OS;
• or via the RDP protocol — if you have a server with Windows OS.

Configure SSH connection

For secure connection to a cloud or dedicated Linux server, use SSH keys instead of a login and password. This is a pair of keys: a private key and a public key. The private key is stored on your local computer, and the public key is placed on the server. After configuring the SSH connection and disabling password access, only devices holding the private key will be able to connect to the server, and the server will be protected from bruteforce attacks (brute-force attacks).

For each administrator, you need to create an SSH key pair and place the public key on the cloud or dedicated server. When creating a key, provide a passphrase (for additional security).

After creating SSH keys, create a user and configure the SSH connection — either when creating a server using user data or for a created server via the CLI. If you use servers with a public IP address, the safest strategy is to configure security settings at the server creation stage using user data.

User data

You can specify user data for a cloud and dedicated server.

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

#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.

CLI

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

1. Open the CLI.

2. Create an admin: user:

   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:

   mkdir /home/admin/.ssh
   cd /home/admin/.ssh

4. Create the authorized_keys: file:

   touch authorized_keys

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

   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:

   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:

   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:

   systemctl restart ssh

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

   ufw allow 2222/tcp

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

    ufw --force enable

11. Restart the server.

Recommendations for using RDP connections

To securely connect via RDP to a cloud or dedicated server running Windows, do not use a public IP address. We recommend using a VPN to access such servers — for example, OpenVPN, WireGuard, or IKEv2/IPsec. To do this, place cloud and dedicated servers that are accessible via a separate VPN gateway in private subnets, or deploy a VPN gateway on the server itself.

Use a separate account for each server administrator.

Additional security tools

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

• Fail2Ban;
• Penalties in OpenSSH;
• CrowdSec.

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);
• Secret Net Studio (Windows);
• Dallas Lock Trusted Boot Tool.

Two-factor authentication

To protect your services from unauthorized access, we recommend using two-factor authentication for additional user identity verification. The service is provided as licenses for using the Multifactor solution.

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

In a Managed Kubernetes cluster, you can control access to virtual resources using the RBAC Authorization (RBAC) mechanism. RBAC allows you to distribute user roles — create different namespaces for different applications and configure user access to pods in the corresponding namespace.

Managed databases

In all DBMSs except Redis, you can manage database users and their privileges. Detailed information on user management is available in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL semi-sync, MySQL sync, and Kafka.

One user is automatically created for the Redis DBMS. The password for this user is set when creating the cluster, and after the cluster is created, it can be changed.

S3

Access to S3 resources is regulated by:

• a role model — determines access within an account and project;
• bucket policy — defines access within a bucket.

When receiving a request for an action in S3, access is first checked by the role model. If the role model allows access, the access policy is checked; if not, access is denied. With an access policy, everything that is not allowed by the policy rules is denied.

To grant access via API or FTP, issue keys.

To access objects in a bucket via your own domain over HTTPS, you need to add a TLS (SSL) certificate. You can issue a certificate from any provider. You can manage certificates through the control panel or the Object Storage API.