Why login with root on the servers?

[gefloh]

Hi,

just recently stumbled over this great project, amazing work you guys are doing, thanks a lot!

Just one question which came into my mind: In all server hardening guides I always read that you should disable root login on a server. Here all my servers are provisioned with public IP addresses and enabled root login. Isn't this a security risk? Or are there technical reasons why the root login is necessary e.g. for Terraform?

Cheers,
Gerhard

[mysticaltech]

@gefloh We just chose to keep the default as given by OpenSUSE MicroOS, as it's easier for configuration. Here's how it's hardened:

openSUSE MicroOS, based on Tumbleweed, is designed to be an immutable, transactional operating system optimized for container and edge computing. While it's true that it comes with a root user by default, the security hardening measures in place help mitigate potential risks.

Some of these security features include:

• Read-only root filesystem: The root filesystem is set to read-only by default, which prevents unauthorized changes to critical system files.
• Atomic updates: MicroOS uses transactional updates that are atomic, meaning they are either applied completely or not at all. This ensures that the system is always in a consistent and stable state.
• Rollback capabilities: If an update causes issues, the system can easily be rolled back to a previous working state, minimizing the impact of any security vulnerabilities introduced by a new update.
• Containerization: MicroOS is designed to run applications in containers, which provides an additional layer of isolation from the host system.
• Regular updates: As MicroOS is based on Tumbleweed, it receives frequent updates, ensuring that the latest security patches are applied promptly.
• Hardened kernel: The kernel used in MicroOS comes with several security features enabled, such as Address Space Layout Randomization (ASLR), which makes it more resistant to potential attacks.
• SELinux enforcing: MicroOS can come with SELinux (Security-Enhanced Linux) in enforcing mode, which means that the system will actively prevent unauthorized actions based on its security policy. This provides an additional layer of protection against potential security vulnerabilities, as it restricts processes and users to the minimum set of privileges required for their tasks.

While having a root user does introduce some level of risk, the security measures built into openSUSE MicroOS help minimize the potential impact.

[mysticaltech]

@gefloh I did not mean to open it up again manually, but you will have to do that if you first close down, touch anything other than the firewall in the kube.tf, and apply again.

So ideally, once the firewall is closed, the kube.tf should be a no-go zone, unless you want to open it up again, then you apply, then you can start playing around with you kube.tf again. Is that clear enough?

[gefloh]

I am not completely sure @mysticaltech . It didn't work for me opening the firewall again with just applying the kube.tf and having changed there only the firewall and nothing else. That would certainly be my preferred way of handling it. So currently, if you block the configured SSH port with applying kube.tf you cannot apply the kube.tf again until you have manually adjusted the firewall (in the Hetzner Console) to accept SSH connections on that port again. Maybe it's a bug? Can you verify this behavior?

[mysticaltech]

If I missed something, please copy paste the complete output of the terraform apply where the error occurs, so that I can see the plan and what caused a component to want to run a remote-provisioner.

[mysticaltech]

@gefloh I will verify on my end, no problem!

[mysticaltech]

@gefloh You are right, once closed it need to be opened manually, and then you can apply and it will work. Kinda not ideal but it's the best we have for now haha.