debops / debops-playbooks

Ansible playbooks used by DebOps project

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Hardening recommendations for common playbook

carlalexander opened this issue · comments

I'm finalizing a DebOps project that runs in a separate playbook. I just have a question about the common playbook that runs when you just call debops before hand.

Do you add extra configuration when you create your own projects? Or do the role defaults follow common sysadmin best practices?

They look good to me, but I'm not a sysadmin per say. I'd like to offer some good defaults. I looked at the examples, but couldn't see much beyond subnet limitations for sshd.

I'm a sysadmin, pick me, pick me! ;-)

DebOps roles and the official playbook are focused on production environment by default. So yes, the defaults I set in roles are what I think is best practice at the time, after doing research about a particuar thing. I try to pick sensible defaults that let you just enable a particular role on a host and after an Ansible run it should be correctly configured.

For example, debops.auth by default randomizes root password, in case that the host was installed from an VM image, or from a template that uses common root password (new password is stored in secret/ directory).

Most of the roles are configured to either allow access from remote hosts if a role is mostly "public", like a webserver, or deny access from remote hosts if role is more "private" like a SMTP server, to prevent abuse. You can then use role default variables to change these settings as you see fit for your environment; for example allow SMTP access from a selected subnet to create a "mail hub" for all your hosts in the cluster to sent mails through.

As for subnet defaults... Can't really pick a good default here, since each enviroment is different. So, in public roles, role is configured to allow connections from anywhere by default, and in private roles, all connections are denied by default.

Perhaps adding a document with list of variables like sshd_whitelist, which you most certainly want to define for your on environment, could be helpful here.

Yay, a sysadmin! 😂

I understand a lot of the underlying function of debops.secret so I felt good about that stuff. I was more worried about the roles. I did notice from the use of debops.ferm to create a safe default firewall. It's discussed a bit in this issue in debops.sshd.

The project I'm working on is going to be OS. I'm trying to make it as user-friendly as possible. The subnet is good for more advanced users, but not as easy for beginners. I just wanted to make sure there weren't other defaults that I should handle.

I'm sure there're tweaks I'll need to do in the future, but I'm glad the defaults are good!

Thanks for the clarification!

OS as in Open Source? Interesting, let me know when you publish it, I'm eager to check it out. :-)

Yep! You'll know when it's published (probably next week).