tapir

Deploy-Keys

Deploy Keys are used to authenticate upload requests. When creating a deploy key, you need to provide the following parameters:

Scope

The scope parameter determines the hierarchy of access. You can choose the level of granularity for the deploy key based on the resource type.

Resource hierarchy:

Depending on the resource type, you can set the scope to one of these levels. The deploy key will grant access to all resources under the specified scope.

Examples

Given the following resources:

  1. Scope: namespace (e.g., namespace == tapir)

    A deploy key with this scope would grant access to all tapir resources:

  1. Scope: name (e.g., namespace == anta, name == compute)

    This scope limits access to the compute resources within the anta namespace:

  1. Scope: provider (e.g., namespace == tapir, name == networking, provider == azure)

    This would restrict access to only the tapir/networking/azure module.

Legacy Deploy keys.

Before version 0.9, deploy keys were not scopable. While it is recommended to migrate to scopable keys, legacy deploy keys remain valid. They are treated as the most restrictive scope (provider for modules and type for providers), limiting access to a specific resource.

Upload a module or provider

To upload a module or provider you need to be authenticated via DeployKey

Upload a module

When you publish a Terraform module, you need a DeployKey giving permission to the new module.

Prerequisites:

NOTE: The zipped module directory layout should follow the Terraform module structure.

Example:

module.zip
├── main.tf
├── outputs.tf
├── README.md
├── variables.tf
└── <any-other-file-or-directory>
What Tapir does on upload
Upload via API

You can upload modules to the registry via its HTTP REST-Api. It will return HTTP status 200 on success.

curl -XPOST  -H 'x-api-key: <API_KEY>' --fail-with-body -F archive=@archive.zip "https://example.corp.com/terraform/modules/v1/<namespace>/<name>/<provider>/<version>"

Tapir has build-in support for several module providers. This means you should follow the naming convention for specific module provider:

AWS: aws
Azure: azurerm
Google: google
Kubernetes: kubernetes

Upload a provider

When you publish a Terraform provider, you need a DeployKey giving permission to the new provider.

Looking for the troubleshooting docs?

To create and build the provider it is highly recommended to use the official HashiCorp provider project template. It uses goreleaser to sign the actual provider binaries. For details see how to prepare release.

Prerequisites:
Upload via API

You can upload provider to the registry via its HTTP REST-Api. It will return HTTP status 200 on success.

curl -XPOST -H 'x-api-key: <API_KEY>' --fail-with-body -F archive=@archive.zip "https://example.corp.com/terraform/providers/v1/<namespace>/<type>/<version>"

Reference a Terraform Module or provider

Prerequisites:

You don’t need to specify the protocol explicit.

Reference a module

module "my-module" {
  source = "example.corp.com/<namespace>/<name>/<provider>"
  version = "<version>"
}

Reference a provider

terraform {
  required_providers {
    foo = {
      source = "example.corp.com/<namespace>/<type>"
    }
  }
}


provider "foo" {
  # Configuration options
}