--- # Multi factor authentication deployment in IT and its effects outside IT --- ## What is mFA/2FA? * Protecting authentication beyond your first factor * First factor stolen/phished: *no impact* * Can protect: * Single-Sign-On (SSO): any web app using the new SSO * SSH: any SLC6, CC7, Centos 8 system... ---- ### Supported 2nd factors * Supported 2nd factors & requirements: * [SSO&SSH] TOTP: smartphone authenticator app * [SSH] Yubico OTP: Yubikey * [SSO] U2F/WebAuthN: physical token (e.g. Yubikey) * SMS not supported anymore: * Not supported natively by Keycloak * Not considered as secure as other options ---- ### How to register a 2nd factor * Registered at first use on the SSO (remotely): * TOTP (smartphone authenticator app) * U2F/WebAuthN (Yubikeys@SSO) * Registered remotely via dedicated website: * Yubico OTP (Yubikeys@SSH): https://sshsetup.web.cern.ch/ * No need to go to the self-service stations at CERN anymore ---- ### Web 2FA authentication  * Password + 2nd factor only * No step-up support, need to logout & re-login ---- ### SSH authentication  * (Password|Kerberos|SSH Key) + 2nd factor * Without kerberos, asking for login for unix service accounts * login must be in `.k5login`  * Protip: Yubikey OTP or TOTP can be entered directly ---- ### Obtaining a Yubikey outside IT * Relatively expensive tokens (~50$): * First batch discounted, but can't count on it * Privately bought Yubikeys not useable for SSH: * Keys need to be configured with keys known by CERN * Not in CERN stores: removed due to inactivity * Might be re-added in the future * CERN IT providing the keys (at cost): * Not tracked through Inventory: to be bought via TID * Let us know ASAP if you will need more that 15-20 keys --- ## Implementing 2FA * New implementation very similar to previous one * Has been used by security team for years * Starting to be used by CS & DB * Tightly integrated into the new SSO * Yubikey OTP supported separately for now * Long term plan to integrate it tighter ---- ### Web 2FA authentication * Fully integrated into new standard SSO * Special option when defining roles  ---- ### SSH 2FA authentication * Configured via puppet's `multifactor` module * Support for new infra: [CRM-3404](https://its.cern.ch/jira/browse/CRM-3404) & [CRM-3420](https://its.cern.ch/jira/browse/CRM-3420) * Fully integrated in Centos 7 and 8 via pam: * Transparent for `ssh`, `scp`, `sftp`, `rsync`, ... * Degraded support on SLC6 (not recommended): * Not using pam, not transparent ---- ### Availability: #### Two independent backends * TOTP & U2F/WebAuthN: * Fully dependent on Keycloak * No other dependency * Yubikey OTPs/SSH: * User-yubikey mapping: Openshift + Postgresql DBOD * Yubikey validation: WebDFS + Oracle DB * To be re-evaluated on the long term (better intregration) * Emergency access/backdoors being discussed --- ## Deployment plan: ### Step 1 -- AIADM & Puppet core Target: March 31st 2020 * Protect AIADM with 2FA * Protect puppet core services with 2FA: * Foreman/Judy: website & API * Teigi applications (API): pwn, tbag, tellme * Mcollective ---- ### Protect puppet service APIs with 2FA * Can't modify the APIs themselves: * Using IP-base whitelists * Transparent for AIADM clusters * Other systems: require equivalent security levels: * List maintained by the Security Team * Access protected by 2FA (any: SSH, web, tool, ...) * Detailed logs of logins & actions sent to Security Team * SSH almost covered by central monitoring * Other applications to be discussed ---- ### Proposed timeline (Step 1) * February 2020: * Users obtain and configure tokens (Yubikeys/TOTP) * Identify servers for IP whitelisting: contact [me](emailto:vincent.brillault@cern.ch)! * Validate/test 2FA deployments: * SSH: `aiadm-multi.cern.ch` * SSO: use `Two-factor authentication` options * March 2020: * Enable 2FA on AIADM (SSH) and Foreman (SSO) * Enable IP restrictions for all APIs * Ensure security level of servers in IP whitelist * Deadline: March 31st (not April 1st) --- ## Deployment plan: ### Step 2.A -- SSH access to IT internals Target: Summer 2020 * Protect access to IT internal systems with 2FA * **Only for admin access in IT, no effect for *standard* users** * User access to LXPLUS not affected * Requiring either direct 2FA or through 2FA bastion * Subject to validation & approval in April 2020 ---- ### SSH access to IT internal systems #### `AIADM or equivalent` * Two options (can be combined): * Through 2FA bastions (AIADM or equivalent): * Single factor authentication on the final system * Detailed logs from the bastion (execlog & netlog) * Direct access to the server with 2FA: * Multifactor configured on the final system * Access logs of the system sent to Security Team * Corresponding toggle added to `base`: * Multifactor configured with IP whitelist (2FA bastions) * IP filter to 2FA bastions only ---- ### Proposed timeline (Step 2.A) * April 2020: * Review of project & approval of next steps * Add new toggle to `base` (default: `nothing`) * May 2020 * Service managers in IT encouraged to change toggle and configure whitelists (bastions, internal connections, ...) * [Optional] Service managers ∉ IT to hardcode `nothing` * June 2020: * Set default to `multifactor` (CC7&C8), IP filter (SLC6): * `nothing` still acceptable outside IT --- ## Deployment plan: ### Step 2.B -- Provisioning services Target: 2020 * Subject to further review & approval * Targeted services: * Openstack for IT tenants * Gitlab for IT users (puppet & packages) * Koji ---- ### Openstack for IT tenants * Needs to be protected: * Access to destructive actions * Access to console: reboot + single-user mode * Pending integration of CLI with OIDC * Actual implementation to be discussed afterwards ---- ### Gitlab for IT users * Needs to be protected: * Puppet configuration * Package sources * 2FA already deployed but not fully supported * Completely disconnected from SSO's 2FA * Major bypass through direct git access * Depending on upstream: hard to improve... * Possibility for puppet (for shared modules & IT hostgroups): * Forbids pushing onto `master` branches * Require 2FA for all users on targeted repositories ---- ### Koji * Needs to be protected: * Packages installed & run * First step: enforce precise ACLs for each and every tag * 2FA restrictions difficult: Gitlab-CI integration... ---- ### Proposed timeline (Step 2.B) * No clear timeline: most problems still open * Targeting 2020 * Subject to review after Step 1 & 2.A --- ## Deployment plan: ### Step 3 -- Other admin accesses in IT * Any adminitrative accesses outside SSH * Anything else, any protocol * Service managers (in IT) should ensure: * Privileged/administrative access protected by 2FA * Access & action logs stored outside of the server * Think about it while adapting to new SSO/group/ldap! --- ## Actions/Timelines ### For people affected ---- ### Get your 2nd factor * Register TOTP on new SSO * [Optional] Obtain a Yubikey (outside IT): * Coordinate key distribution within your group * Grouped TID to Experiments/Departments/... * Register it: * On new SSO * On https://sshsetup.web.cern.ch/ * Test 2FA Authentication: * On new SSO * On aiadm-multi.cern.ch ---- ### Projected changes * February 2020: * Contact me it using Foreman/tbag/teigi/roger APIs * March 2020: * 2FA enabled on AIADM and APIs * May 2020: * [TBC] Set *toggle* in `base` to `nothing` (outside IT) * June 2020: * [TBC] 2FA or IP restriction for admin access within IT --- ## Questions? ---