As a Platform.sh customer, your protection is paramount and every single one of your projects is secure. For Enterprise and Elite customer projects we go the extra mile and offer a rich selection of enhanced security features, which can be used right now.
- Multifactor authentication (MFA) over SSH
- Firewall
- Reverse proxies for external origins
Let’s dig into each of them.
MFA over SSH
MFA increases security by requiring users to use more than one method to identify themselves. So even if malicious actors gain access to one method, they can’t access your systems.
You can now enforce MFA over SSH within your organization. With this option enabled, every contributor within your organization must use MFA to run Git commands or SSH into an environment.
MFA over SSH requires users to have the command line interface (CLI), as this is what’s used for authentication. With MFA enforced, users can no longer authenticate with SSH keys. Instead, they’re granted short-lived SSH certificates. See more details about this process in a previous blog post.
To enable MFA over SSH, simply open a support ticket with the request. You can have it enabled for all projects within your organization or a select list of projects. Just let us know which you prefer.
Firewall
You might want to lock down your network so your apps can only access certain sites. If so, you can take advantage of our firewall to secure access.
We recently added the firewall
property to .platform.app.yaml
so you can specify IP addresses, ports, and protocols for access. This feature gives you the flexibility to secure your network according to your specific rules and helps ensure PCI compliance.
You can even filter outbound traffic by domain, which is even more specific and secure. For example, if you use an IP address for a service with a CDN, you have to allow the IP address for the CDN. This means that you’re allowing potentially hundreds or thousands of other servers also using that CDN.
To use the firewall, simply specify the firewall
key in your .platform.app.yaml
file like in the following example:
firewall:
outbound:
- protocol: tcp
ips: ["192.0.2.0/24"]
ports: [443]
- protocol: tcp
ips: ["203.0.113.123"]
- protocol: tcp
domains: ["api.example.com"]
ports: [80, 443]
These rules define what outbound traffic is allowed and anything unspecified is blocked. They don’t affect inbound traffic.
See all of the details about adding firewalls in our firewall documentation.
Reverse proxies for external origins
Proxy routes allow you to pass requests to locations outside your Platform.sh project, including to a different Platform.sh project. This means you can use the same base URL across different projects, such as pointing example.com/fr
to one project and example.com/de
to another.
Visitors to your site (example.com
in this case) see everything as coming from one location. But you’re free to handle the requests as you like in the background, so you can offload services to projects specialized in handling them.
You can define an external proxy for your Platform.sh project by defining a route in your .platform/routes.yaml
file like in the following example:
https://{default}/no-slash:
type: proxy
to: https://example.net
https://{default}/with-slash:
type: proxy
to: https://example.org/
If your default domain is example.com
, this means that requests for https://example.com/no-slash/index.html
are passed to https://example.net/no-slash/index.html
. The full path is preserved in the proxied request.
But requests for https://example.com/with-slash/index.html
are passed to https://example.org/index.html
. The trailing slash means that part of the path is overwritten.
As you can see, you have flexibility in defining your external proxies. See all of your options in our proxy route documentation.
Note that for larger projects our recommendation is to handle this through a CDN. The router scales with the size of the project and can potentially become a bottleneck and a single point of failure for all projects in the domain.