Skip to main content
Identity & Access Management

Identity & Access Management

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 users with the Account Owner or User Administrator role can add users and change their details and roles. To simplify user management, you can group users into groups.

By default, for all users after registration and filling out a profile, two-factor authentication is enabled. 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 the authenticator app 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 configure authentication in the control panel using the 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 — 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 User Administrator can set restrictions — users can log in to the account only from IP addresses and subnets that have been added to the authorized list.

If you need to share access to the control panel or resources with someone else, do not share your data. The account owner and User Administrator can create an additional user for control panel access or a service user for program access, see the User types and roles instructions for more.

Cloud and dedicated servers⁠

Cloud servers can be accessed through the console in the control panel, and the dedicated servers are accessed via KVM console. If you connect to the server through other CLIs to provide secure remote access to the infrastructure, connect to the server:

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

Configure SSH connection⁠

For secure connection to the cloud or dedicated server with Linux OS, use SSH keys instead of login and password. The pair of keys are 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 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, you need Create an SSH key pair and place the public key on the cloud or dedicated server. When creating a key for additional protection, specify a passphrase.

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

You can specify user data for the 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

Where:

  • name: admin — a user is createdadmin;
  • sudo: ['ALL=(ALL) NOPASSWD:ALL'] — allows the user to execute commands through sudo without asking for a password;
  • groups: sudo — adds the user to a group sudo;
  • lock_passwd: true — blocks password login for the 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 a firewall UFW (Uncomplicated Firewall) which is needed to restrict access to the SSH port;
  • commands with sed -i under runcmd — change the default port 22 to 2222, disable password login and root-user connection, and enable key authentication.

Recommendations for using the RDP connection⁠

In order to safely connect via RDP to the cloud or dedicated server with Windows OS, do not use a public IP address. We recommend using a VPN to access such servers — e.g. OpenVPN, WireGuard or IKEv2/IPsec. To do this, place the servers in 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 security 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 assign user roles — create different namespaces for different applications and configure user access to pods in the appropriate namespace.

Managed databases⁠

In all DBMSs except Redis, you can manage database users and their privileges. See the following instructions for more details: 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 edited.

Object storage⁠

Access to object storage resources is regulated by:

When receiving a request for an action in the object store, access is first checked by 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 access via API or FTP, issue the keys.

To access objects in the container through 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 via control panel.