Automate Drupal security updates using DropGuard
Drop Guard is a continuous security solution for Drupal. It is a service that can automate or at least part-automate the tasks of keeping a Drupal site up to date, a task that we all know is important but few of us actually enjoy. Automating updates can help you meet client SLA’s as well as releasing valuable developer time.
Drop Guard is in the process of developing tight integration with some of the big Drupal hosts out there such as Acquia and Pantheon*. This integration will make the process of using Drop Guard for sites using those hosting platforms easier and more powerful. However in my opinion Drop Guard has enough flexibility as a continuous security solution to make it a valuable asset to anyone.
*It is worth noting that there are currently a few shortcomings when using with a Pantheon hosted site. I have listed these at the bottom of this article as they will make more sense there.
Below is a short tutorial on how to get started with using Drop Guard on your Drupal sites.
Installation on a site and project creation on Drop Guard
Install the Drop Guard module and push to live
On the Drop Guard site, add a project and follow the instructions. You basically need to add the git url that you see on the dev branch and ensure you have added the Drop Guard SSH key to your Pantheon account or even better created a bot user account on Pantheon and add the SSH to that user account.
When prompted from the Drop Guard site copy the user id and token and paste in the Drop Guard module configuration on the site you are installing this on. On this page you will also need to select the live branch and specify the url as this is where Drop Guard monitors for available updates.
Once you have finished the steps on the Drop Guard site, on the overview page you should see that git and the site are connected:
At this point the project is paused as you will first need to configure some update behaviours for the different update types (update severity).
Configure update behaviors
From the project page click on the edit this project tab and then on the Update behaviours tab. You can set the update behaviours from this page and group your update types but I personally found it more useful to use the expert mode by clicking on the link at the bottom of the page. You can now set a specific update behaviour for each update type.
There are several options you need to configure for each severity:
Update mode: Choose whether Drop Guard should automate the update, create a task for you to action manually or skip update.
Testing mode: The two options are whether you’d like to manually test after the Drop Guard commit or to skip tests. This option determines the status of the task in Drop Guard.
Git branch mode: Choose whether you want Drop Guard to create a feature branch for the update task or to commit to a specified branch. Currently on Pantheon you cannot instruct Drop Guard to create a feature branch though they have told me that this is in their road map.
Source Git branch: Select which branch you want to commit to.
Git tag name: Depending on what your Git workflow is you can optionally configure Drop Guard to tag update commits. There is a list of available tokens you can use.
Stop update process if the patch can not be reapplied: If you have applied a patch to the module being updated Drop Guard will re-apply the patch for you. Use this option to stop the update if it can not be reapplied.
Now that we have created our update behaviours the next step is to create Drop Guard events.
Events start to give this whole process a workflow. Events and event actions are triggered based on the Drop Guard task status such as New updates are available or ready to test.
For each different status you can trigger various actions such as Send an email, merge a branch or Execute SSH command.
Click on the Events tab and you’ll see the following window:
Expand the status you would like to trigger an action for and you’ll see a list of possible actions. This section will take some tweaking but is key in implementing a workflow that meets your requirements.
It’s worth noting that for each action on an event you’ll need to select which update types this event is relevant to. To do this you’ll need to expand a status, add an action and you’ll then see a drop down list of the update types.
The example below triggers on the test passed status. The triggered action is set to merge the designated update branch to master once this status is met. It is applied to all security updates and excludes normal updates.
Tip - Drop Guard offers Project management integration for Jira and Redmine. We do not use either of those so I have created an action to email [email protected] when the status is set to ready to test. Our support desk software will create a ticket when it received that email.
Let Drop Guard take the lead
Once you have finished creating your events click on the Back to project overview tab. You will see a list of available updates along with some valuable information about the update such as current version and target version.
Whenever you’re ready to relinquish some control to Drop Guard, unpause your project from the overview page and check for updates.
After a few minutes of growing anticipation and possibly anxiety, depending on how you have set up your update behaviours and events you’ll see the commits on x branch or you’ll see them as tasks on the tasks tab to be manually actioned. From the tasks tab you can change task status and trigger your actions that you set up in your events.
You now have the peace of mind that you can keep your Drupal site up to date with minimal fuss and that your SLA’s on security updates will be met.
If you are using Drop Guard to monitor security updates on a Pantheon hosted website there a few points to be aware of:
No support for feature branch creation yet.
Full automation all the way to live is not possible solely through the Drop Guard events. You will need to implement a cocktail of Terminus and Quicksilver (for Pantheon) or another CI solution such as CircleCI.
I strongly recommend that if this is the first time you’re implementing Drop Guard that you do so on a dummy site and that you test your workflow thoroughly before rolling it out to production sites. It won’t be fun explaining to key stakeholders that the site is down due to automated security updates that were deployed by a Drop Guard Pantheon bot!