|
|
# Meeting 2021 03 25
|
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
## Kristian Klausen Application (postponed)
|
|
|
|
|
|
Kristian applied through a [post](https://lists.archlinux.org/pipermail/arch-devops/2021-March/000502.html) on arch-devops.
|
|
|
|
|
|
## Make 2FA optional for regular users (postponed)
|
|
|
|
|
|
Issue: [#295](https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/295)
|
|
|
|
|
|
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](https://gitlab.archlinux.org/archlinux/infrastructure/-/wikis/meetings/2020-09-05#mfa-bypass)), so 2FA was made mandatory for everyone ([!80](https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/80)).
|
|
|
|
|
|
Keycloak still doesn't support our use-case AFAIK (mandatory 2FA for only some roles), but we can create our own [authenticator SPI](https://www.keycloak.org/docs/latest/server_development/#_auth_spi) and implement it yourself.
|
|
|
|
|
|
PoC: https://github.com/klausenbusk/keycloak-conditional-2fa (relevant logic [here](https://github.com/klausenbusk/keycloak-conditional-2fa/blob/57060cb421805bdfdaf425066a01f27cf1661732/src/main/java/com/github/klausenbusk/authenticator/Conditional2faAuthenticator.java#L44-L74))
|
|
|
* If 2FA (OTP or WebAuthn) is configured or the user has the role $role the "Conditional 2fa" flow is "REQUIRED"
|
|
|
|
|
|
![image](https://gitlab.archlinux.org/archlinux/infrastructure/uploads/568caf61a156dd7464863bcf7da0c7ef/image.png)
|
|
|
|
|
|
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
|
|
|
|
|
|
* Check or create a ticket for optional 2FA support in Keycloak
|
|
|
* Alternative, provide 2FA backup codes or force a user to configure two 2FA methods (maybe one with pass-otp?)
|
|
|
|
|
|
## Stop mangling the mailing list mails
|
|
|
|
|
|
The mailing list configuration was changed on [2020-12-29](https://lists.archlinux.org/pipermail/arch-dev-public/2020-December/030248.html), so all lists use `@lists.archlinux.org`.
|
|
|
|
|
|
At the same time, configuration differences between the lists was fixed, which means that every list now:
|
|
|
* Rewrites the `Subject` to include the list name
|
|
|
* Rewrites the `From` to avoid DMARC/spam issues
|
|
|
|
|
|
This did result in a few complains from the pacman developers, as it broke their workflow, ex [pacman@c8f335ae](https://git.archlinux.org/pacman.git/commit/?id=c8f335aef75aa749d4b48f0774a1b9de93d06cdd):
|
|
|
|
|
|
> author: Emil Velikov via pacman-dev <pacman-dev@lists.archlinux.org>
|
|
|
|
|
|
It has been suggested that we stop mangling the mails and just forward them as received (as all the big lists do), this [shouldn't cause any issues](https://people.kernel.org/monsieuricon/subspace-mailing-list-server) as long as the original sender is probably configured.
|
|
|
|
|
|
This only user facing change, is that the users need to click `Reply List` or `Reply All`(do we have a policy on that?) instead of `Reply`. In the past concerns were raised, that it could be a challenge for the less tech savvy users (aur-\*) to adapt to this change.
|
|
|
|
|
|
### Actionables
|
|
|
|
|
|
* Handle after mailman migration
|
|
|
* Create tracking issue
|
|
|
|
|
|
### Who
|
|
|
|
|
|
* wCPO
|
|
|
|
|
|
## Access to logs
|
|
|
|
|
|
There is some ongoing work on centralized logging ([!316](https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/316)) 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](https://grafana.com/docs/grafana/latest/enterprise/datasource_permissions/) instead of per organisation.
|
|
|
|
|
|
[1] Grafana doesn't validate the requests, it just proxies them directly to the service
|
|
|
|
|
|
### Ideas
|
|
|
|
|
|
* Create a different Grafana organisation perhaps?
|
|
|
* Pursuit a enterprise license?
|
|
|
* A separate Grafana instance for devops?
|
|
|
* Prometheus "firewall"?
|
|
|
|
|
|
## Keycloak mailpass integration
|
|
|
|
|
|
Lambdaclan has worked on getting a PoC working.
|
|
|
|
|
|
Please review his work!
|
|
|
|
|
|
Edit (by Lambdaclan):
|
|
|
|
|
|
- preliminary review has been completed and requested changes were implemented
|
|
|
- please see the open threads and todo/toverify lists on the top of the PR and let me know how to proceed
|
|
|
- more specifically we need to decide
|
|
|
- where the project should live (repo etc)
|
|
|
- https://gitlab.archlinux.org/archlinux/keycloak-archlinux-theme
|
|
|
- what are the next steps, do we need CI etc
|
|
|
- yes
|
|
|
- how do we package and deploy the endpoint
|
|
|
- PKGBUILD ([example](https://github.com/archlinux/svntogit-community/blob/packages/keycloak-metrics-spi/trunk/PKGBUILD)) + ansible magic
|
|
|
- jelly and freewsa want to maintain it in the community repo
|
|
|
- do we re-adjust the customizations to the account console and extract them to a different page instead of editing the existing personal info page (easier to maintain?)
|
|
|
- yes
|
|
|
- do we merge the theme customizations with the current theme (located in infra) or move the theme to live with the endpoint repo since they now depend on each other - regardless we need the theme for testing purposes
|
|
|
- monorepo FTW! - https://gitlab.archlinux.org/archlinux/keycloak-archlinux-theme
|
|
|
|
|
|
If there is anything else that needs to be dealt with then please let me know. Thank you.
|
|
|
|
|
|
### Actionables
|
|
|
|
|
|
* Create a repository for lambdaclan to work in. |
|
|
\ No newline at end of file |