Guidance
Migrating from GOV.UK PaaS
GOV.UK PaaS is a live service. However, we are decommissioning the service, with a planned retirement date of 23 December 2023. You can read our blog post announcement.
To understand how you can prepare to migrate your services and how the GOV.UK PaaS team can help, read our migration guidance
Penetration testing
It is your responsibility to penetration test your app to make sure it’s secure. Note that you can only penetration test your app; you cannot penetration test the platform.
You must send the below information to gov-uk-paas-support@digital.cabinet-office.gov.uk so that we are aware of your penetration test and can approve it.
Supplied by penetration tester |
---|
Tester phone number |
Emergency email and phone number contact details |
Will the requests originate from the tester’s office? |
The origin IPs |
Peak bandwidth that the tests will consume in gigabits per second |
Peak number of requests per second the tests will perform |
Start and end dates and times of the test in the format YYYY-MM-DDTHH:MM:SSZ for example 2017-09-26T09:00:00Z |
Is it possible to stop the test immediately if there is an issue? |
If your request is approved, your penetration test is only authorised for the dates and times you have specified.
Further information
You can find more information on penetration testing in:
Connect a PHP app to PostgreSQL or MySQL
If your PHP app uses a PostgreSQL or MySQL database, it must connect to that database securely using SSL.
These instructions assume that your app uses the PHP Data Objects (PDO) library to connect to either a MySQL or PostgreSQL backing service database.
You must configure your app to use a SSL connection by inserting the following code into the config.ini
file located within .bp-config/php/php.ini.d/
:
extension=pdo.so
extension=pdo_mysql.so OR pdo_pgsql.so
extension=openssl.so
You should use this method instead of the now-deprecated method of defining PHP extensions in the .bp-config/options.json
buildpack config file.
You can find more information about how to configure the PHP buildpack at the PHP buildpack configuration documentation.
Refer to the code below for examples on how to connect your app to MySQL or PostgreSQL.
Example code - MySQL
$vcapServices = json_decode(getenv('VCAP_SERVICES'), true);
$creds = $vcapServices['mysql'][0]['credentials'];
try {
$pdo = new PDO(
sprintf('mysql:host=%s;port=%d;dbname=%s', $creds['host'], $creds['port'], $creds['name']),
$creds['username'],
$creds['password'],
array(PDO::MYSQL_ATTR_SSL_CAPATH => '/etc/ssl/certs')
);
printf("Result was: %s\n", $pdo->query('SELECT 1')->fetchColumn());
} catch(Expection $e) {
printf("Error: %s\n", $e->getMessage());
}
Example code - PostgreSQL
$vcapServices = json_decode(getenv('VCAP_SERVICES'), true);
$creds = $vcapServices['postgres'][0]['credentials'];
try {
$pdo = new PDO(
sprintf('pgsql:host=%s;port=%d;dbname=%s', $creds['host'], $creds['port'], $creds['name']),
$creds['username'],
$creds['password']
);
printf("Result was: %s\n", $pdo->query('SELECT 1')->fetchColumn());
} catch(Expection $e) {
printf("Error: %s\n", $e->getMessage());
}
Connect Drupal to MySQL
If your Drupal app uses MySQL, it must connect to the database securely using SSL. You must configure Drupal to use a SSL connection by:
- enabling required PHP extensions
- setting up the database connection
Enable required PHP extensions
- Create a
mysql.ini
file within.bp-config/php/php.ini.d/
. Add the following code to this .ini file:
extension=pdo.so extension=pdo_mysql.so extension=openssl.so
You should use this method instead of the now-deprecated method of defining PHP extensions in the
.bp-config/options.json
buildpack config file.
You can find more information about how to configure the PHP buildpack at the PHP buildpack configuration documentation.
Set up the database connection
Include the following code in your Drupal configuration file, located by default at sites/default/settings.php
:
$vcapServices = json_decode(getenv('VCAP_SERVICES'), true);
$mysqlCreds = $vcapServices['mysql'][0]['credentials'];
$databases['default']['default'] = array(
'driver' => 'mysql',
'database' => $mysqlCreds['name'],
'username' => $mysqlCreds['username'],
'password' => $mysqlCreds['password'],
'host' => $mysqlCreds['host'],
'port' => $mysqlCreds['port'],
'prefix' => 'drupal_',
'collation' => 'utf8mb4_general_ci', // For Drupal 8
// 'collation' => 'utf8_general_ci', // For Drupal 7 or earlier
'pdo' => array(PDO::MYSQL_ATTR_SSL_CAPATH => '/etc/ssl/certs')
);
Connect Wordpress to MySQL
Your Wordpress app must connect to MySQL securely using SSL. You must configure Wordpress to use a SSL connection by:
- enabling required PHP extensions
- setting up the database connection
- patching Wordpress to enable SSL connections
Enable required PHP extensions
- Create a
mysql.ini
file within.bp-config/php/php.ini.d/
. - Add the following code to this .ini file:
extension=mysqli.so
extension=openssl.so
You should use this method instead of the deprecated method of defining PHP extensions in the .bp-config/options.json
buildpack config file.
You can find more information about how to configure the PHP buildpack at the PHP buildpack configuration documentation.
Set up the database connection
Replace the database configuration code in your wp-config.php
file with the following code:
$vcapServices = json_decode(getenv('VCAP_SERVICES'), true);
$mysqlCreds = $vcapServices['mysql'][0]['credentials'];
define('DB_NAME', $mysqlCreds["name"]);
define('DB_USER', $mysqlCreds["username"]);
define('DB_PASSWORD', $mysqlCreds["password"]);
define('DB_HOST', $mysqlCreds["host"]);
define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);
define('MYSQL_SSL_CAPATH', "/etc/ssl/certs");
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
Patch Wordpress to enable SSL connections
Insert the following code before the mysqli_real_connect
function call in the wp-includes/wp-db.php
file:
[...]
// Included block start
mysqli_ssl_set($this->dbh, null, null, null, MYSQL_SSL_CAPATH, null);
// Included block end
if ( WP_DEBUG ) {
mysqli_real_connect( $this->dbh, $host, $this->dbuser, $this->dbpassword, null, $port, $socket, $client_flags );
} else {
@mysqli_real_connect( $this->dbh, $host, $this->dbuser, $this->dbpassword, null, $port, $socket, $client_flags );
}
[...]
Isolation segments
What isolation segments are
Cells are the underlying servers that build and run your apps. GOV.UK PaaS schedules your apps on a large number of identical cells.
GOV.UK PaaS has other cells which are slightly different to the regular cells on which your apps run. These cells are called isolation segments.
You can specify an isolation segments for a space, or for an organisation.
Apps within a space
When you specify an isolation segment for a space, all apps in that space run on the isolation segment’s cells, rather than on the normal cells.
Apps within an organisation
When you specify an isolation segment for an organisation, all apps in that organisation run on the isolation segment’s cells, rather than on the normal cells.
What isolation segments are available
We currently offer one isolation segment:
egress-restricted-1
Egress restricted
When your apps run in an egress restricted isolation segment, they can:
- serve traffic from the internet (if you map a public route)
- serve traffic internally (if you map a private route)
- talk to other apps within the platform (if you set up network policies)
However, your apps cannot:
- talk to the internet
- make external DNS requests
How you can use isolation segments
If we have enabled an isolation segment for your organisation, and if you are an org manager, you can change how your apps are scheduled using the isolation segment.
For example, the following commands will create a new space and make sure that any app you push within that space will run on a cell with egress restrictions:
cf create-space my-locked-down-space
cf set-space-isolation-segment my-locked-down-space egress-restricted-1
Contact us at gov-uk-paas-support@digital.cabinet-office.gov.uk if you would like us to enable an isolation segment for your organisation.
Useful Cloud Foundry plugins
There are some community-contributed plugins that are useful in different situations:
- App AutoScaler plugin lets you set and adjust the autoscaling rules for your applications from your command line interface (CLI)
- Buildpack usage plugin allows you to check if you’re using a buildpack that will be affected when the GOV.UK Platform as a Service (PaaS) team updates the default buildpacks
- Log Cache CLI plugin gives you more advanced log filtering from the log buffer by allowing you to filter by time, type or class of log
- Open plugin gives you the links to your applications from your command line and opens your browser directly to them
- Route Lookup CLI plugin determines which route is attached to which app
- Top plugin lets you see how your applications are performing within GOV.UK PaaS and warns if you are running out of memory or CPU
The Cloud Foundry open source community maintains these plugins, and we are not responsible for updating them.
Other Cloud Foundry plugins are also available.
Using the Conduit plugin
Some GOV.UK PaaS backing services (PostgreSQL, MySQL and Redis) only accept connections from GOV.UK PaaS apps. You’ll need to connect through a GOV.UK PaaS app to access one of these backing services from your local machine. We have created the Conduit plugin and written some guidance on using the Conduit plugin to simplify this process.
Conduit lets you connect to your remote backing service instances from your local system. This allows you to use the standard tool for your backing service, for example, psql
for PostgreSQL or mysql
for MySQL CLI tools to make backups and interrogate your backing services.
Connect to a backing service from your local machine
To install this plugin, run the following code from the command line:
cf install-plugin conduit
You’ll see the following warning:
Attention: Plugins are binaries written by potentially untrusted authors.
Install and use plugins at your own risk.
Do you want to uninstall the existing plugin and install conduit VERSION? [yN]:
Select ‘y’ to continue with the installation.
Once the plugin has finished installing, run the following code to get credentials and a local address through which to access the backing service:
cf conduit SERVICE_NAME
SERVICE_NAME
should be a unique descriptive name for this service instance.
To connect to the backing service using your chosen tools, use the username, password, port and URI given in the output from Conduit.
The following services are ready for you to connect to:
- service: SERVICE_NAME (BACKING_SERVICE_TYPE)
host: 127.0.0.1
jdbcuri: jdbc:postgresql://127.0.0.1:PORT/A_RESOURCE?password=PASSWORD&user=USERNAME
name: A_RESOURCE
password: PASSWORD
port: PORT
uri: postgres://USERNAME:PASSOWRD@127.0.0.1:PORT/A_RESOURCE
username: USERNAME
Where: - BACKING_SERVICE_TYPE is the type of the backing service (for example, PostgreSQL) - USERNAME is the username to connect to the service - PASSWORD is the password for the user - PORT is the port on which to connect - A_RESOURCE is the name of the resource as given by the service provider (for example, the database name)
Run cf conduit --help
for more options, and refer to the Conduit README for more information on how to use the plugin.
See the PostgreSQL documentation and MySQL documentation for specific information on how to use Conduit with those backing services.
Deleting Conduit applications
The Conduit application creates and deploys GOV.UK PaaS apps with names like conduit_RANDOM_STRING
(for example, conduit_aeganmtr
) in your space. Conduit should tidy the apps up by itself when the session ends, but if it does not, it is safe to delete them yourself. Before you delete them, make sure nobody else on your team is using Conduit to connect to the same database.
Static egress IP addresses
To locate the GOV.UK PaaS static egress Internet Protocol (IP) addresses, log in to your GOV.UK PaaS account and go to the relevant link (depending on where your account is located):
These are also available from the footer of our website for easy access when you are logged in.