Skip to main content

Access control

Control panel

In Servercore, 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 rights to resources are set at the level of user types and roles. Only the Account Owner or users with the role of iam_admin can add users and change their data and roles. To simplify user management, you can organize users into groups.

By default, two-factor authent ication is enabled for all users after registration and filling out a profile. With two-factor authentication, you need to enter a password and a one-time confirmation code to log in to your account. The confirmation code can be received via the application-authenticator or by SMS to the phone number 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 set up authentication in the control panel using Single Sign-On (SSO) technology. To do this, use identity federation, a centralized service for managing organizational structure, setting up integration with the employee directory, and controlling user access to company resources. When using federation, 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 the user with the role of iam_admin can set restrictions — users will be able to log in to the account only from IP addresses and subnets that they have added to the allowed list.

If you need to share dashboard access or resources with someone, do not share your data. Account owner and user with the role iam_admin can create an additional user for control panel access or a service user for program access, see the Access Control in Servercore Products manual for more information.

Cloud and dedicated servers

You can connect to cloud servers through the console in the control panel, and you can connect to dedicated servers through the KVM console. If you connect to a server through other CLIs to provide secure remote access to the infrastructure, connect to the server:

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

Configure SSH connection

To securely connect to a cloud or dedicated Linux server, use SSH keys instead of login and password. These are a pair of keys: a private key and a public key. The private key is stored on the local computer and the public key is hosted on the server. After configuring SSH connection and disabling password access, only devices with the private key will be able to connect to the server, and the server will be protected from bruteforce attacks.

For each administrator, create a pair of SSH keys and place the public key on a cloud or dedicated server. When creating a key for additional security, specify a passphrase.

After creating SSH keys, create a user and configure SSH connection — when creating a server using user data or for a created server through the 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.

You can specify user data for cloud and dedicated server.

Example of creating a user and configuring 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

Here:

  • name: admin — user is created admin;
  • sudo: ['ALL=(ALL) NOPASSWD:ALL']. — allows the user to execute commands via sudo without being prompted for a password;
  • groups: sudo — adds the user to the group sudo;
  • lock_passwd: true — locks password login for user admin;
  • <public_ssh_key> admin@test under ssh_authorized_keys — 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 needed 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, enable key authentication.

Recommendations for using an RDP connection

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

Use a separate account for each server administrator.

Additional safety tools

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

Managed Kubernetes

In a Managed Kubernetes cluster, you can manage 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 appropriate namespace.

Cloud databases

In all DBMSs except Redis, you can manage database users and their privileges. For more information about user management, see 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 during cluster creation, and can be changed after cluster creation.

S3

Access to S3 resources is regulated:

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

For API or FTP access ,issue keys.

In order to access objects in the baket via your own domain via 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.