Mobile/Projects/APK Factory/Meeting 2013 11 19

From MozillaWiki
Jump to: navigation, search

Proposed Architecture (requirements not nailed down yet)


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 - 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:

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:

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 Sentry - stending stack traces, exceptions 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.