3 ms·
Production code has no unauthenticated access to source. In all the cases I know, there was a data push for dynamic configurations from source to production, u
by puzzle 8y ago
Production code has no unauthenticated access to source. In all the cases I know, there was a data push for dynamic configurations from source to production, usually adding access control, auditing, validation, etc. Static configurations would be baked into the container image.
That said, it looks like in this case he would been able to turn on access to google3, through a special flag that is probably meant for internal GAE apps that work on source code. Presumably, the flag allows the app to use a GAE proxy that authenticates to Piper and provides a filesystem-like interface. It's not clear what would have happened at this point, because it is likely there exists a finer grained quota for source access than just all of GAE. These kinds of new RPC traffic would have been visible in Dapper and Census data, plus there are booby traps everywhere aka defense in depth.
- girvo 8y agoRight, but he wasn’t doing this in a production environment, so I wonder if he could’ve got access to source still.. thoughts?
- puzzle 8y agoAt the end of the day, even a non-production GAE environment runs on Borg, talks to GFS and Bigtable, etc. They're not going to run the entire stack on bare metal. The environments will have different configurations, will be backed by different Borg jobs, hopefully will run under different Borg identities, etc. The articles about Piper and co. have made it clear that it ran on top of Bigtable first and then Spanner, i.e. in the production network, spread over ten locations. There's file level auditing and access control. It would be very dumb of them not to have intrusion and anomaly detection in place.