20231018.md

# 2023-10-18
## Participants - use of github handle is preferred
- @markus-hentsch
- @JuanPTM
- @90n20
- @reqa
- @garloff
- @o-otte

## Recurring items
* Announcements
* Who is presenting in weekly community call and transforming etherpad to minutes in GitHub?
    - @reqa
* Additional agenda items

## Agenda
* [Board](https://github.com/orgs/SovereignCloudStack/projects/6/views/27) cleaning
-> Tue afternoon prep w/ reqa/juanptm/garloff (AI @garloff)

### Progress report federation
* working on [#314](https://github.com/SovereignCloudStack/issues/issues/314): keycloak overlay
    * waiting for authorization
    * repo to be created and harbor robot secret
        * See 2023-10-04: @garloff to create repo (add to github-manager), enable in zuul (@o-otte), add harbor robot secrets (think about namespaces: @garloff with @jschoone / dNation), @berendt to help with plugging, enabling renovate, @JuanPTM to create keycloak overlay there
            * PR [github-manager#162](https://github.com/SovereignCloudStack/github-manager/pull/162)
        * zuul plumbing needed for image building
* [#405](https://github.com/SovereignCloudStack/issues/issues/405) - Federated users created as ephemeral users in *default* domain
    * Cristi Nikolla will review
* [#650](https://github.com/osism/issues/issues/650) - support for TLRZ / killermöhre bug rerpot
    * Config files from testbed (which work for us) don't seem to work there, waiting for full logs to analyze further
    * Progress is slow
        * Data protection questions
        * Support contract questions
        * @garloff to discuss with B1 how to deal with it
* Integration testing missing => R6 goal (@garloff to create Epic)
    * Test cases need to be created
    * Test environment needs to be defined
        * Some pieces may need mocking
    * Test framework (zuul - @master-caster) needs to be understood
    * IAM testing workshop needed (at Dresden Hackathon?) @reqa

### Updates pentesting
* Testbed was updated (to R5)
    * Ports on manager now closed (except ssh and wireguard)
* Internal view: Still ports open with potential vulnerabilities
    * Nothing critical thus far
    * Summary available as sec. advisory
        * Use nextcloud for longer reports
* Will need to move to a physical environment soon
    * Needs alignment with PlusServer (@garloff to approach @frosty-geek)

### Roles (@markus-hentsch)

- talked with artcodix and AOV about potential testing of the Domain Manager standard on their greenfield setups
    - potential Keycloak problems (see below)
    - standardized roles in general are desired
    - exposing the list of (IDs and names of) all domains to Domain Managers (due to current OpenStack implementation limitation) might be considered critical (if identifiable names are used)
        - Upstream contribution wanted! (@markus-hentsch, @josefinesei)
- Domain Manager standard and Keycloak problems
    - 1. users always mapped to proxy domain, not to their actual target domain [#405]
    - 2. unable to provision specific roles (e.g. domain-manager) to individual users in Keycloak?
        - prereq: needs role creation beforehand (Keystone deploy vs. Keycloak)
        - could be applied via group membership
    - AI @markus-hentsch: Link artcodix w/ @JuanPTM and @reqa
- upcoming role standard ([issues#396](https://github.com/SovereignCloudStack/issues/issues/396))
    - = predefine policy.yaml files for all services that have an API
        - Q: does SCS include a fixed set of services?
            - AI @garloff -> @berendt, @fkr: Put all services in a number of buckets:
                1. Standard services (expected to be available with each SCS deployment)
                2. Optional but fully supported
                3. Optional, no guarantees (Tech Preview ...)
                4. Unavailable
    - upstream current: "member", "reader", "admin" roles
        - We should use these without any changes (and have them changed upstream if needed -- if we really need to diverge, use a different name from upstream)
    - upstream upcoming (ETA 2024): add "manager" role (intended for projects only! not domains)
        - see https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html
    - Q: should we go for "member", "reader", "admin" *and* "manager" prematurely? Any other roles required?
        - "manager": later, when it converges upstream (could give a hint that this is intended in the future)
        - we should strive for aligning with upstream as much as possible, i.e. no unnecessary changes to the default roles already defined by OpenStack, only sensible tweaks/extensions
        - possible additional roles from SCS:
            - auditor (reader with some addtl restrictions to protect sensitive data)
            - domain-manager