Mobile/Projects/APK Factory/Meeting 2013 11 19
Proposed Architecture (requirements not nailed down yet)
https://www.lucidchart.com/documents/view/4262-9680-5285454a-bd0a-4a150a00de40
HSM
We have a cache in front of Marketplace already (maybe odn't need squid)
HSM won't store all keys, just a CA cert which would sign the keys.
Solitude - payment provider (We don't use that)
Trunion - receipt signing,, app signing - https://github.com/mozilla/trunion can be configured to talk directly to the HSM
Reuse Trunion here (OpenSSL library to connect to HSM) (Used in Marketplace Payments in two different ways)
Hardware Security Module - gives you a key, you fetch over a secure channel
You generate the key and you can't get it out
HSM maybe overkill - encryption key on disk, roate keys... threat model - steal key - you could author malware
Many people publish their keys in their source code, because if you lose the key...
Backup is important
Marketplace - Apps have keys to sign Marketplace requests. Low threat model, these keys are encrypted by on disk key... encrpytoed blobs in MySQL (encrypted with openssl)
As an example, we store application payment keys as AES encrypted blobs in the DB: https://github.com/mozilla/solitude/blob/master/lib/sellers/models.py#L21
We use on-disk key files to encrypt/decrypt the database values and the key files can be rotated at any time. Example for how the key files are managed: https://github.com/andymckay/django-aesfield/
CHALLANGES: We should investigate packaging the Android SDK for deployment early, as this will be the hardest part of the project.
- headless install possible, austin described procedure
- Legal compliance with licenses
We might not automate this and just have a puppet manifest that makes this work
DATA STORAGE: APK Cache - Maybe use S3 APK DB - manifest, version #, file system path (MySQL) APK Key Store - Trunion (if we use HSM)
Master key on disk, encrypt keys in database perioidically roate keys
Aside from Android SDK, the other hard part of this project is managing developer keys. Backup of DB and Key Store is mission critical. Loss of developer keys will lock a developer out of their app
HORIZONTAL SCALING: APK DB and Key Store are a centralized resource. All other sub-components can be horitzonally scaled in a single DC or multiple DC. We probably do not need multiple DC to reduce latency, as main consumer is marketplace to generate APK files. There is no User Interface. (Requirements TBD)
PACKAGING: rpm deployment - some JS apps npm install -> package rpm npm - same problems as pip, not always SSL... commit node_modules to node repo Problem is integrity of code. npm doesn't pin modules to a hash, so you don't actually know what your getting when you do npm install foo@1.2.3
MONITORING: Nagios, statsd - New Relic compatibility would be nice http://newrelic.com/nodejs Sentry - stending stack traces, exceptions https://github.com/mattrobenolt/raven-node statsd - point it at a collecter and prefix it with 'dev-' (dev, stage environment available for all three of these tools)
CONFIGURATION: A list of JavaScript files which will shadow each others values. Environment variables which will shadow config files. Command line arguments which will shadow ENV variables.
