Self-Hosted: Public Gateway
This article applies to: Self-Hosted
The pglombardo/pwpush-public-gateway container is a cut down version of the pglombardo/pwpush container, designed to be hosted publicly and only deliver pushes to end users while keeping the internal infrastructure secure.
This container is ideal for organizations that want to provide a public-facing push gateway with a limited feature set. This container doesn’t include user logins, registrations, the Administration dashboard and many other features.
It exists solely to deliver pushes to end users.
Benefits
- Improved Security: By hosting the public-facing push gateway in a separate container, you can reduce the attack surface of your internal infrastructure. This setup allows you to isolate the public-facing components from the internal components, making it more difficult for attackers to access sensitive information.
- Flexibility: The
pglombardo/pwpush-public-gatewaycontainer can be hosted in a public cloud, on-premises, or in a hybrid environment, giving you more flexibility in terms of deployment options. - Scalability: The public-facing push gateway can be scaled independently of the internal infrastructure, allowing you to handle increased traffic and demand without affecting the performance of your internal systems.
- Reduced Complexity: By separating the public-facing components from the internal components, you can reduce the complexity of your infrastructure and make it easier to manage and maintain.
Security Considerations
The pglombardo/pwpush-public-gateway container employs feature segmentation, a well-established security strategy that reduces the attack surface by dividing a system into isolated segments. This approach is commonly used in networking, services, and applications to prevent unauthorized access, lateral movement and limit the spread of malware.
The concept of segmentation is not new, and numerous papers and resources have been published on the topic. For example:
- Design Secure Network Segmentation Approach - SANS Institute 2021
- Secure Network Design: Micro Segmentation - SANS Institute 2021
- Implement Network Segmentation and Encryption in Cloud Environments - NSA 2024
The pglombardo/pwpush-public-gateway container is an additional layer of security for your organization, helping to protect against potential threats and vulnerabilities.
Deployment Architecture Example
The public proxy image (pglombardo/pwpush-public-gateway) is meant to be hosted externally facing your end users while the full fledge container image (pglombardo/pwpush) hosted internally for full functionality for your internal team.
The following is an example diagram to illustrate the basic idea for a deployment:
Note: Except for PWP__OVERRIDE_BASE_URL, the pwpush-public-gateway container should generally have the same settings and environment variables as the pwpush container. This ensures that both containers connect to the same database and have the same application configuration.
Tips & Best Practices
- Always use the same version (Docker tag) for both containers.
- Both containers should use the same configuration with
settings.ymlor environment variables. - Both containers need to see the same database to perform their roles.
Note: When in-app configuration is released and all configuration is stored in the DB, number 2 will be eliminated. More news on this coming soon. In development/pre-release screenshots will be in the newsletter.
Ephemeral Database
ephemeral meaning: transitory, transient, fleeting, passing, short-lived, momentary, brief, short, cursory, temporary, impermanent, short-term; fading, evanescent, fugitive, fly-by-night; literary fugacious. ANTONYMS long-lived, permanent.
Password Pusher supports an ephemeral datastore out of the box if another database isn’t specified.
This ephemeral datastore is a SQLite3 database stored in the Docker container and available to only that one docker container.
In the case of the Public Gateway, both containers need to share a common datastore.
With databases like PostgreSQL, MariaDB and others, this is done simply by using the same DATABASE_URL environment variable but in the case of SQLite3, for the two containers to share the same datastore, the SQLite3 directory needs to be stored on a mounted Docker volume between both containers.
If you would like to use the ephemeral datastore with the public gateway container, see How to Persist the Ephemeral Database across Container Restarts .