cmd: Add --init for installing plugins automatically

[wata727]

Fixes #1067

This PR adds a new option, --init, to install plugins automatically. This will improve the user experience of plugins on Azure and GCP and make it easier to extend with other plugins.

Extend the schema of the configuration to achieve this goal:

plugin "aws" {
  enabled = true

  version = "0.4.0"
  source = "github.com/terraform-linters/tflint-ruleset-aws"

  signing_key = <<-KEY
  -----BEGIN PGP PUBLIC KEY BLOCK-----

  mQINBFzpPOMBEADOat4P4z0jvXaYdhfy+UcGivb2XYgGSPQycTgeW1YuGLYdfrwz
  9okJj9pMMWgt/HpW8WrJOLv7fGecFT3eIVGDOzyT8j2GIRJdXjv8ZbZIn1Q+1V72
  AkqlyThflWOZf8GFrOw+UAR1OASzR00EDxC9BqWtW5YZYfwFUQnmhxU+9Cd92e6i
  ...
  KEY
}

The version refers to the release tag (without leading "v"), and the source refers to the repository in which the plugin is released. At this point, the github.com hostname isn't used for anything, but we'll give it for future extensibility.

Note that this schema is based on Packer, but does not support version constraints. We will only provide automation for the installation of the specific version first.

The signing_key refers GPG public signing key of the third-party plugin developer. Plugins under terraform-linters such as tflint-ruleset-aws and tflint-ruleset-azurerm can use the built-in signing key, so this attribute can be omitted. Other than that, in principle, we encourage you to set a signing key to preventing supply chain attacks.

With these attributes are added, if you run the following command, the plugins will be installed automatically.

% tflint --init
Installing `aws` plugin...
Installed `aws` (source: github.com/terraform-linters/tflint-ruleset-aws, version: 0.4.0)
% tflint -v
TFLint version 0.28.1
+ ruleset.aws (0.4.0)

Plugins that are installed automatically must meet the following rules:

• The release must be tagged with a name like v1.1.1
• The release must contain an asset with a name like tflint-ruleset-{name}_{GOOS}_{GOARCH}.zip
• The zip file must contain a binary named tflint-ruleset-{name} (tflint-ruleset-{name}.exe in Windows)
• The release must contain a checksum file for the zip file with the name checksums.txt
• The checksum file must contain a sha256 hash and filename

If you configure signing_key, the release must additionally meet the following rules:

• The release must contain a signature file for the checksum file with the name checksums.txt.sig
• The signature file must be binary OpenPGP format

This change does not affect existing plugin systems. If you omit the version and source, the binaries under .tflint.d/plugins will be referenced as before. If specified, the binaries will be placed under a directory such as .tflint.d/plugins/github.com/terraform-linters/tflint-ruleset-aws/0.4.0.

TODO

• Verify signature for downloaded checksum
• Verify checksum for downloaded plugins
• Fix/Add tests
• Write documentation

[bendrucker]

Nice! I think it would be a good idea to break this out to its own command. golangci-lint has a run command but also accepts a path in place of a command, maybe we could do something like that.

Aside from matching Terraform, separating dependency downloads is important for caching. In CI you want a manifest file you can hash and use as a cache key to persist the downloaded dependencies.

[wata727]

Good point. I thought a manifest/lock file is not needed to simplify the problem, but it certainly does help with caching.
At this stage, is it possible to avoid the problem by using the hash of the config file (.tflint.hcl) as a cache key?

[bendrucker]

At this stage, is it possible to avoid the problem by using the hash of the config file (.tflint.hcl) as a cache key?

Yep! Because exact versions are specified and there's no transitive deps, there should be no real need for a lock file, other than to reduce some unnecessary cache misses.