I don't quite know the way to achieve what you want to, but I can say I
took a slightly different approach. I used a single container with systemd
running MariaDB, PHP-FPM and Apache all in one. Then, I used CloudFlare in
front of everything. Then, it's protected from the world, but I don't have
to run a reverse proxy myself. My setup is documented deeply here:
A simplified drawing might look like this:
World -> CloudFlare -> podman run wordpress(Apache->PHP-FPM->MariaDB)
I think it gives risk parity with much less management. In fact, I would
argue that my Read Only approach is an upgrade in security.
On Mon, Oct 12, 2020 at 5:48 PM Peter Buffon <pabuffon(a)gmail.com> wrote:
I'm currently looking for advice on using Podman to implement
what I think
is a fairly common application scheme, deploying a WordPress instance with
a MariaDB backend and Nginx as a reverse-proxy.
Ideally I'd like to recreate a DMZ approach where the reverse proxy
doesn't have access to the database or any other containers on the host. I
have almost accomplished this with Docker Compose by attaching a frontend
network to the reverse proxy and the application containers and a backend
network to the application and database containers. This is a complicated
approach and doesn't solve the issue of all application containers being
accessible from the reverse proxy container.
I have tried two different approaches to accomplish something similar with
Podman, but they both ended with essentially the same result.
Method one: Enclose all three containers in a single pod. These pods can
access each other via localhost:port. This approach is not ideal because
the reverse proxy container has access to both the application and database
Method two: Create a new network, cni-podman0, with the dnsname CNI plugin
and each container is created in its own pod. This approach is also not
ideal because any container on the cni-podman0 network can access any other
container on the same network using the pod's name (even if containers and
pods do not have published ports).
Any suggestions on where to go from here? Could SELinux or BPF be
possible solutions or am I missing an easier solution? I also thought
about assigning IP addresses to each pod and using the firewall CNI plugin
to lock down access by IP and port, but limited documentation on
integrating Firewalld and Podman has limited me from experimenting further.
I realize Kubernete's service and network policy features essentially
solves this problem, but I am looking for a simplified single host approach
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
The Delicate Art of Product Management with Open Source:
Product Management - Containers, Red Hat Enterprise Linux & OpenShift