# attendance - Luca Filipozzi (SPI; Debian) - David Duncan (AWS) - Bastian Blank (credativ for Microsoft; Debian) - Lucas Kanashiro (Collabora for Google) - Jimmy Kaplowitz (SPI; Debian) - Max Illfelder (Google) - Tomasz Rybak (Debian) # discussion ## business ### requirements - account not held by an individual (no SPOF) - account should be for 'organization' not for 'individual' - account could use standard terms and conditions; could negotiate some changes such indemnity ### current status - AWS: - Bromberger-tied account under AWS VP - used primarily by Noah to build and publish Debian cloud images - Also hosts some Debian QA projects - AZU: - credativ-tied account in public and regional Azure clouds, used for mirror and image publishing - internal name: credativ (used more deeply than just 'owner id') - need to know how it is used, and after that to decide what we do with it - external name: Debian - GCP: - debian-cloud and related projects owned by and billed to Google - debian-cloud is where Google's official Debian images are publiished - debian-cloud-experiments is where Debian cloud team people can tinker - debian-infra used for the mirror project - Collabora-tied account under which Debian cloud images are tested and improved (built and released by Google) - SPI-tied account under G-Suite (used so far by salsa, and separately also freedesktop.org) - Salsa expenses paid through credit applied to the account by Google - Freedesktop.org expenses paid through SPI debit card by fdo's funds ### action items - AWS - structure: - AWS VP (cost covered by AWS VP; owned by AWS) - Debian publication account (owned by SPI; delegated to Debian; new) - Separate Debian publication account for AWS GovCloud region - Debian engineering account (owned by SPI; delegated to Debian; new) - ArchLinux publication account (ditto) - ArchLinux engineering account (ditto) - SPI (cost covered by SPI; owned by SPI) - Debian bar (owned by SPI; delegated to Debian; new) - freedesktop (owned by SPI; delegated to freedeskop; new) - etc. - schedule cadence meetings both business and technical considerations - AZU - structure: - SPI for Debian (some subscriptions covered by AZU, others paid; owned by SPI) - Debian mirror subscription - Debian cloud-build subscription - Debian bar subscription (not sponsored) - SPI for ArchLinux - ArchLinux subscription (sponsored) - SPI for freedesktop - freedesktop subscription (not sponsored) - mirror - complete - GCE - SPI G Suite organzation (linked to spi-inc.org GCP organization) - folders - Debian GCP folder - Debian cloud-build project (sponsored) - Debian bar project (not sponsored) - ArchLinux GCP folder - ArchLinux project (sponsored) - Freedesktop GCP - freedesktop project (not sponsored) - billing - Multiple billing accounts, one or more per project (e.g. "Debian - Salsa") - One or more payment profiles (e.g. "SPI debit card", "future SPI credit card", "invoice", "something Google-internal maybe") - Payment profiles can be used for one or more billing accounts - Billing accounts can be used for one or more projects - DO - ? - Gandi - ? ### contacts - AWS: - administrative: David Duncan (davdunc@amazon.com) - technical: noahm@debian.org - AZU: - administrative: Stephen Zarkos - technical: Bastian Blank - GCP: - administrative: Shanmugam (Sham) Kulandaivel (shankul@google.com) - technical: Zach Marano (zmarano@google.com) - SPI: ### constraints - AWS - no cap, but use must be frugal and directed - not-for-profit use - AZU - high cap, use for mirrors and testing - GCE - no cap, but use must be frugal and directed ## technical ### mirror networks - requirements: - Debian wants users of Debian Images in cloud providers to have fastest/cheapest/easist access to package mirror - fastest in ms - cheapest in $ (no network cost) - easiest -> preconfigured (ideally deb.debian.org) - the cloud providers want an internal Debian mirror network in each of their geographic region in order to reduce network costs (to the provider) and to provide fast access to users - AWS - deisres: - siimlar to Debian - options: - (A) use CloudFront in front of EC2 Instances in three AWS Regions (NA, EU, OC) supplemented with AWS Route53 entries to drive traffic to the correct place - (B) use EC2 Instances in each Aws Regions, each with an AWS ALB, supplemented with AWS Route53 entries (or fallback to DNS names using region names) - waldi has tried (A) under the jeb's account using terraform (torn down); will need to be recreated under SPI/Debian - constraints / decision factors: - cost (AWS decision) - effort (Debian prefers A if it is reliable) - reliability (Debian assume A is reliable) - concerns: - private endpoints in VPCs ("private link") -> future work - actions: - davdunc to confirm we can use CloudFornt - noahm will speak with the AWS folks tha run the Amazon Linux yum mirrors to see if there's a different approach to consider - AZU - desires: - same as Debian - options: - (A) no CDN equivalent - (B) Traffic Manager (DNS) -> Load Balancer -> two instance in each reagion - option (B) exists (more or less) under credativ account; will need to be recreated under SPI/Debian - constraints / decision factors: - only choice (B) - cost / effort / reliability - concerns: - none that we know of - actions: - waldi to consider moving inside debian.org - GCE - desires: - same as Debian - "enterprise mirror" ... control the point in time that packages are available (like snapshot.debian.org or ipfs) - options: - (A) CloudCDN ... VM instances in multiple regions ... single name handles per region service - (B) instances per region with a load balancer ... not preferred by GCE with hostname tricks - (C) a new secret google service that might do the equivalent ... - option (A) exists (more or less) under debian-infra project and is blocking on DSA; will need to be recreated under SPI/Debian - constraints / decision factors: - cost (GCE prefers (C) followed by (A); Debian same) - effort (Debian prefers (A) - reliability (Debian assumes (C) and (A) are more reliable than (B)) - timing ... GCE will have decisions regarding (C) by end of year - concerns: - private endpoitns in VPCs -> future work but "magic" - actions: - zmarano will reply by end of year for option (C) - lucaf to review waldi's ticket from 9mo ago - how does the above interact with deb.debian.org? does it need to? - no, we propose ${vendor}.mirror.debian.org where ${vendor} is - AWS -> delegate to Route53 - AZU -> CNAME - GCE -> A record (magic IP address) - and is set at cloud image creation time and possibly overridden in cloud-init - how do we make use of above for worldwide access to deb.debian.org? - AWS -> good to go if we use (A) - AZU -> no - GCE -> TBD (zmarano to respond if yes and whether (C) or (A)) - https as default - this is a certificate management problem - AWS -> would prefer; use ACM - AZU -> would work with effort because load balancer is TCP not HTTPS; need to push certs to every backend instance - GCE -> would prefer; for (C), will work magically; for (A), certificate management exists from waldi - is set at cloud image creation time - AWS - waldi has tried stuff - davdunc can find us a resource - AZU - waldi knows most - GCE - jimmy knows most ### requirements - SPI does not wish to run SSO for every Associated Project - accounts for people and service accounts - each Associated Project can tie SSO ### - overview Debian: LDAP as protocol (LDAP--) OpenLDAP based. Customised, uses posix users. Debian user schema with additional attributes memberOf attribute, not group with member attribute UserDIR for authentication, not LDAP itself event-driven way of propagating changes to machines Especially as there are machines around the world, we don't want to have use full LDAP and to give full access to strange machines Debian uses it, SPI, ganeth, etc. sso written by Enrico. x509 based, browser has client certificate For clouds we'd need new LDAP or some facade. SAML, OAuth2 or something along those lines Or some synchronisation (if above does not work) We keep copy of relevant data in cloud and push changes Just like we do now with UserDIR Federated provider? AWS: roles (ephemeral users) No such functionality elsewhere; we'd need to have user objects there Lowest common denominator Users, groups, etc. Then problem: authentication. How to manange passwords? IDP-based ephemeral user objects AWS. Associate role to group of users Needs to be done in our own LDAP. Attach role to LDAP group, not AWS user group (in IAM) Debian group gets attached role. During synchronisation, not during authentication. SAML is for assertions. User authentitets to us and then we request/pass token AWS user can belong to many groups. But can only have one role G For humans. There need to exist google account for person. We can (but do not need to) push password Roles - created in Google Auth can also be SAML LDAP group -> Google group ability to push full posix, including ssh keys We can instantiate users. sync using API - we need to write code ourselves experience across platforms should be consistent AWS: sync no sync using API: yes sync + SAML (no), but Noah needs to check it. Still no - uses role behind pure SAML - yes, ephemeral roles Google: sync yes, but bad hashing choice sync + SAML: yes pure saml: no, they require G account Azure: sync: probably not, Zach is checking sync + saml: pure saml: yes sync and AD connect, federated model. Azure ID would go to our LDAP? More than one AWS project - then we'll need to have sync to all of them Lowest common denominator, maybe prefered choice: sync using API We don't put passwords, users need to set it themselves. When account is deleted from Debian, it'll also be deleted from clouds. In either case we won't care about password AWS - prefers using roles Azure Internally uses AD ID? Google: we need user But role can be attached to group User and group on Debian side In platform attachment priviledges to groups (not users!) Google authentication best practices: https://cloud.google.com/blog/products/identity-security/using-your-existing-identity-management-system-with-google-cloud-platform The likely way to apply this to Debian is Google Cloud Directory Sync + authenticating via SAML IdP. # Storing credentials to access clouds To run tests use gitlab Protected Account Also - authorisation of those roles/user Credential rotations, etc Mirrors 4 people are ready for ops: * Tomasz Rybak * Ross * Noah * Bastien We should make sure that mirrors are reliable as they will be used by all our instances in clouds Marketplace publication Contractual requirements; we should do general ToS review before creating accounts, and publishing images Accounts. New ones, so new IDs -> we need to have transition plan AWS: Jeb account: no way of detaching it from owner and move to Debian/SPI We publish Buster to new account, and old (Stretch) to old one, so people have continuity and we avoid confusion Blog note that we'll migrate between accounts Need for legal revision before we publish Buster beta (freeze, Jan 2019) Azure Subscription Metadata, publisher id: credativ description (JSON): can be changed So discoverability "Debian" but creation requires publisher id, so "credativ" Create alias for marketplace. To timeline for this feature from Azure Currently Credativ is publishing, but they should do it through Debian/SPI account Mirrors. Credativ also manages them for Azure. Do we move this to SPI account? It's less clean situation as mirrors are not as official as images. Also we have university-run mirrors, not under Debian control. GCE We have SPI account Images are not tied to account But images are tied to project, which is owner by Google right now? There might be possibility to hand over this project. We might need to create more projects for tests, etc.