• Microservices in Docker containers • Jenkins • build pipelines • multiple steps • security-check step • runs a suite of security tests • Notification system for failures & runbook • Take aways
Platform as a Service • Mesos • distributed job scheduler • Marathon • Mesos framework for long running tasks • Chronos • Mesos framework to schedule batch jobs
• autoscaling cluster & resource specification • move from: • hundreds of specialized servers to • heterogenous Mesos agents • SOA architecture • operational ownership of individual services • from operations team to the service authors
• Docker image • runs the service • same image multiple use cases: worker daemon vs web task • contains all the code necessary for the service • Service: • stateless • filesystem I/O but ephemeral disk • log to external processors (Yelp: Scribe or Kafka) • all checked, all good
a set of tests at every build • high level security health of the service • something changed? • actionable alerts for failures • faster response time from team
root • Dockerfile • Yelp maintained Docker images, no public images • Latest images • no packages pinned to certain versions • .dockerignore contains .git
high entropy strings from entering our code base • assumes the existing code has no secrets • checks only the new code • solution loosely based off truffleHog
• get around the libc incompatibilities with rspec • moving everything to python • race condition between the Ubuntu packages that are updated upstream and the Docker base images we build daily • some services are not built regularly
• run our PaaS (PaaSTA) • use our containerisation solution (Docker) • write high-level security tests • integrate them in your build pipeline • open source our security tests suite next year
containers • build pipeline: multiple steps • security-check • runs a set of tests and send notifications • most important - service owners: • more aware of the security of their service • involved in keeping it safe