drutiny/plugin-acquia

Acquia checks for Drutiny

Drutiny - automated site auditing

A generic Drupal site auditing and optional remediation tool.

Installation

This repository is a baseline frame and not recommended to install by itself unless you're planning on building your own auditing tool based on top of Drutiny.

You can install Drutiny into your project with composer.

composer require drutiny/drutiny ^3.6.0

Drutiny has native target support for Git and Drush. If you wish to use these types of targets, you must install the underlying software.

Usage

Drutiny is a command line tool that can be called from the composer vendor bin directory:

./vendor/bin/drutiny

Finding targets to audit

Drutiny has a number of connectors that allow you to discover and access "Targets" to audit. Use the target:sources command to learn which sources are available.

./vendor/bin/drutiny target:sources`

When supported by the target source, use the target:list command to list all the available targets from a given source:

# List all available targets through DDEV.
./vendor/bin/drutiny target:list ddev

Finding policies available to run

Drutiny comes with a policy:list command that lists all the policies available to audit against.

./vendor/bin/drutiny policy:list

Policies provided by other packages such as drutiny/plugin-distro-common will also appear here, if they are installed.

Installing Drutiny Plugins

Additional Drutiny policies, audits, profiles and commands can be installed with composer.

$ composer search drutiny

Running an Audit

An audit of a single policy can be run against a site by using policy:audit and passing the policy name and site target:

./vendor/bin/drutiny policy:audit Drupal-8:PageCacheExpiry @drupalvm.dev

The command above would audit the site that resolved to the @drupalvm.dev drush alias against the Drupal-8:PageCacheExpiry policy.

Some policies have parameters you can specify which can be passed in at call time. Use policy:info to find out more about the parameters available for a check.

./vendor/bin/drutiny policy:audit -p value=600 Drupal-8:PageCacheExpiry @drupalvm.dev

Audits are self-contained classes that are simple to read and understand. Policies are simple YAML files that determine how to use Audit classes. Therefore, Drutiny can be extended very easily to audit for your own unique requirements. Pull requests are welcome as well, please see the contributing guide.

Running a profile of checks

A site audit is running a collection of checks that make up a profile. This allows you to audit against a specific standard, policy or best practice. Drutiny comes with some base profiles which you can find using profile:list. You can run a profile with profile:run in a simlar format to policy:audit.

./vendor/bin/drutiny profile:run d8 @drupalvm.dev

Parameters can not be passed in at runtime for profiles but are instead predefined by the profile itself.

Getting help

Because this is a Symfony Console application, you have some other familiar commands:

./vendor/bin/drutiny help profile:run

In particular, if you use the -vvv argument, then you will see all the drush commands, and SSH commands printed to the screen.

Credits

• Theodoros Ploumis for creating the logo for Drutiny.

plugin-acquia's Issues

Policy: MemcacheEnabled - duplicate policy

The MemcacheEnabled policy is a duplicate of the D8 plugin MemcacheEnabled policy. We should remove this policy and update any references to the D8 plugin version. There is nothing specific about this policy for Acquia.

Policy: No Domains Defined in Cloud

Check to ensure an environment has custom domains added so the default Acquia domains are not in use.

Update the documentation for Acquia Cloud API v2 Target

To Reproduce
The command run to produce the error:

./vendor/bin/drutiny profile:run d8_health_analysis acquia:<hash> -f html --uri=<site>

Error output

$ ./vendor/bin/drutiny profile:run d8_health_analysis acquia:<hash> -f html --uri=<site>
[error]

In Exec.php line 45:

  The command "ssh  <sitegroup>.prod@ded-[redacted].prod.hosting.acquia.com 'echo [redacted] | base64 --decode | sh'" failed.

  Exit Code: 255(Unknown error)

  Working directory: /Users/mia.alsaif/Desktop/drutiny-cs-adaptor

  Output:
  ================


  Error Output:
  ================
  regis.prod@ded-[redacted].prod.hosting.acquia.com: Permission denied (publickey).

Expected behavior
This error is due to not having proper permissions set up in Acquia Cloud's teams and permissions. The error messaging should contain some more description text notifying the user to set up their permissions or use a different Target.

Also, the README file should be updated to mention that the Acquia Target requires proper teams and permission access.

Policy: Ensure Valid SSL

Audit domains for a given environment and report on which support a valid SSL connection.
Since WAF/CDNs can be in front of Acquia, no DNS trickery should be included. That should be done on the local machine if required.

Environment variables are not available for Acquia Cloud Site Factory applications

When running any policy that leverages or extends the EnvironmentAnalysis class against a ACSF application the following error occurs:

     Client error: `GET https://cloud.acquia.com/api/environments/4195-99cffb0a-bbbd-42a4-950f-56082e613313/variables` resulted in a `404 Not Found` response:
{
    "error": "not_available",
    "message": "Environment variables are not available for Acquia Cloud Site Factory ap (truncated...)

The EnvironmentAnalysis class fetches environment variable data from the API

    $sandbox->setParameter('variables', $client->getEnvironmentsVariables([
      'environmentId' => $environment['id']
    ]));

We need to not do that when ACSF is being assessed.