What to do with old FreeIPA accounts?¶

At the moment, we already have some accounts in FreeIPA that are not used since a long, long time. The password is expired and I see a high potential that the owners of those accounts silently left the openSUSE heroes. While it should not be a big deal to leave the accounts as they are (once the owners log in, they are asked to renew their password - and that's it), I see a high potential to sum up some dead accounts in an "only infrastructure" related database. For me, this includes the potential for security risks (as - for example - nobody really knows if a hacker might crack and misuse such an account) and also makes it harder to keep an overview about active members.

So I like to ask if we could agree on disabling a user which password has been expired for more than 6 months?

This would leave the user account (reserved) in the database, but the user will be unable to log-in.
This also allows to filter the inactive accounts and only see the active users.

GDPR -> Saltify account removal¶

As we get more requests for complete deletion of accounts, I think it is time to think about a way to automate as much as possible even in this direction.

I'm thinking of something like:

• User sends ticket for deletion
• MF-IT (or whoever) disables the user and does other "magic" stuff
• the requests ends again on the openSUSE heroes plate
• any Hero could do something like: salt '*' cmd.run '/root/bin/remove_user $login' which would do whatever is needed on the systems to remove the user
  • disabling/deleting the user on FreeIPA
  • remove the user from the community.o.o database
  • removing the user from any other database / application
  • remove any local files (like cron jobs, home directories, files) and processes
  • remove the users SSH keys from Gitlab
  • disable/remove the user in Gitlab
  • check planet.o.o feeds for this user - and creates issues or PR's to remove him
• send back a status report about the stuff done on the machines
• enhance the output with additional information which other parties might need to get informed

IMHO this should give us - as Heroes - also a good overview, where users might have their data stored and which systems are in place and using data.

Internal SSL CA for servers¶

I know at least three services, that use SSL certificates for secure communication:

• NRPE (currently using own script)
• MySQL/MariaDB (self signed)
• PostgreSQL (self signed?)

While FreeIPA allows to generate certificates for "known hosts", so far we tried to avoid FreeIPA for anything else than user management. But internal SSL certificates are needed - and the certificates for the Galera Cluster hosts are already outdated and need a renewal. So how to proceed here: shouldn't we have an internal "certbot" that can be used to generate SSL certificates for services?