@alistek, I see you know PCI DSS, anyone else who is familiar with the PCI DSS requirements, please jump in as well.

I'm busy reading up on PCI DSS and trying to design a stack (including hosting) that will comply with PCI DSS.

My first choice, I want to run things in the cloud, self-managed servers is a lot more of a mission to make them comply. AWS seems compliant and so does Google Cloud - since I already use Google Cloud and know it fairly well, this seems to be a fairly easy choice.

So now that my infrastructure is considered compliant, the next choice is which operating system to choose. CentOS seems very security focussed, but seeing as it's a full-fledged operating system, I'll also need to strip a lot of things out, run an expensive anti-virus on there, manage my own updates, patches etc. I was looking at CoreOS, it's a very minimal OS that will only be running read-only containers - do I still need to run an anti-virus on CoreOS if you can't do anything on it other than start and stop containers?

Once I have the OS nailed down, I need to choose a container technology, I don't know raw LXC very well, Docker I do know very well, but it seems like Docker is running processes as root, so Rocket on CoreOS seems like the better choice as it's much more security focussed and doesn't run as root. Again, do I need to run an anti-virus on the Docker image if it's read-only? Udo Seidel from Amadeus said they bring the docker image to the Anti Virus instead of bringing the Anti Virus to the Docker Image - how does that work?

To secure the Docker images, I should probably run my own registry and build my own image from scratch to be used as a base image or is it ok to use official docker images on Docker Hub? Would there be any preference for which registry I use? Google Cloud already offers a Docker Registry, so if my image is scanned somehow and then pushed to Google Cloud's Docker Registry and somebody has verified the Dockerfile, can I consider that image compliant?

A lot of the compliance seems to deal with access to the servers, if the servers are all read-only, deployments are all automated and new docker images are built and deployed on CoreOS after deleting the old image, can I ignore that part of the compliance? If I can prove that the only thing that has access to the instances is the deployment box, that eliminates humans from getting any access to those servers.

In terms of logging, if I push all logs from all containers to the Google Logging infrastructure or my own logging infrastructure, is that considered good enough for compliance in terms of the logging requirements?

What are the requirements for keeping these containers up to date, if I rebuild my images once a week and redeploy them automatically, would that be considered good enough in terms of the patching requirements? CoreOS seems to do its own updates.

Segmenting the network into 4 sections, one section's containers will have DB access, one section's containers will deal with card data, one will contain all the frontends and one section will contain something like RabbitMQ. Frontends will directly communicate with API, API will communicate with processing layer via RabbitMQ and processing layer will communicate with application that has database access also via RabbitMQ, but via a different virtual host in RabbitMQ - that should be sufficient separation to qualify for the 3 layers requirements between your frontend and database?

With regards to third-party providers, if I'm sending emails via SendGrid as example, will my system be considered non-compliant if SendGrid is not compliant?

Anything else I need to take into consideration when trying to make a container-stack compliant?