Skip to content
Snippets Groups Projects

2021 04 08

Last edited by Jelle van der Waa

DevOps Meeting 2021-04-08

luna migration

grazz checked luna again and come to the conclusion there is no way to test the new mailman setup without testing.

Jelle volunteered to migrate the cgit repositories to a new vps temporarly and/or gitlab?

  • Do we redirect repositories to gitlab
    • Yes
  • What to do with projects/git.archlinux.org domains
    • Nginx redirect (map)
  • Do we want to archive old git repositories? Our self or on for example https://archive.softwareheritage.org/

Make 2FA optional for regular users (postponed from the last meeting)

Issue: #295 (closed)

2FA was optional for "regular users" (not staff and not "external contributor") ~6 months ago, but it was easy to bypass (2020-09-05 meeting notes), so 2FA was made mandatory for everyone (!80 (merged)).

Keycloak still doesn't support our use-case AFAIK (mandatory 2FA for only some roles), but we can create our own authenticator SPI and implement it yourself.

Keycloak shortcomings

PoC: https://github.com/klausenbusk/keycloak-conditional-2fa (relevant logic here)

  • If 2FA (OTP or WebAuthn) is configured or the user has the role $role the "Conditional 2fa" flow is "REQUIRED"

image

Pros:

  • Less time spent on 2FA resets as less experienced 2FA users aren't forced to use 2FA

Cons:

  • more custom things to a complex system such as keycloak

Question: Should we do it?

Actionables

  • Review/test our code, document it and consider upstreaming the code
  • Document reset users 2FA procedure #282 (closed)
  • What do we do when a user has no access to his email address anymore?
    • Backup email address in Keycloak
    • If not: Bad luck, game over!
  • Is there is a ticket for keycloak, for enforcing 2FA based on an assigned role
    • The conditional otp "thing" can do that, but only for OTP

Stop mangling the mailing list mails

Issue opened at the last meeting: #296 (closed)

Access to the logs

There is some ongoing work on centralized logging (!316 (closed)) and a question popped up.

Who should have access to the logs? Grafana is currently accessible by all staff, but giving all staff access to the logs is probably not a good idea.

Due to the way Grafana works[1], we can’t give people access to only some logs, it is either access to everything or no access. Sven did reach out to Grafana Labs for a enterprise license, which would allow us to limit access to a datasource per user / team instead of per organisation.

[1] Grafana doesn’t validate the requests, it just proxies them directly to the service

Ideas:

  • Limit monitoring.al.org devops only
  • Create a different Grafana organisation perhaps?
    • Create a new organisation for devops and only add the data source there
  • Pursuit an enterprise license?
    • Not a viable option
  • A separate Grafana instance for devops? *
  • Prometheus “firewall”? *
  • Public instance (at some point)

Actionables

Restrict access to Grafana for only devops as logs can contain sensitive information.

Comments

    Please register or sign in to add a comment.