Deploy Keys are used to authenticate upload requests. When creating a deploy key, you need to provide the following parameters:
resource-type
: Specifies whether the deploy key is for a module
or a provider
.source
: The location of the module or provider, typically a Git repository.scope
: Defines the access level for the deploy key, allowing fine-grained control.namespace
: The namespace of the resource (applies to both module
and provider
).name
: The name of the resource (applies to module
).type
: The type of resource (applies to provider
).provider
: The provider of the resource (applies to module
).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:
<namespace>/<name>/<provider>
<namespace>/<type>
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.
Given the following resources:
tapir/networking/aws
tapir/networking/azure
tapir/compute/aws
tapir/compute/azure
anta/networking/aws
anta/networking/azure
anta/compute/aws
anta/compute/azure
Scope: namespace
(e.g., namespace == tapir
)
A deploy key with this scope would grant access to all tapir
resources:
tapir/networking/aws
tapir/networking/azure
tapir/compute/aws
tapir/compute/azure
Scope: name
(e.g., namespace == anta
, name == compute
)
This scope limits access to the compute
resources within the anta
namespace:
anta/compute/aws
anta/compute/azure
Scope: provider
(e.g., namespace == tapir
, name == networking
, provider == azure
)
This would restrict access to only the tapir/networking/azure
module.
tapir/networking/azure
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.
To upload a module or provider you need to be authenticated via DeployKey
When you publish a Terraform module, you need a DeployKey giving permission to the new module.
myorg/vpc/aws
.v
prefix. (e.g.1.0.0
or v1.0.0
).zip
is supported.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>
example
will be removedMACOS
)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
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.
myorg/my-provider
.v
prefix. (e.g. v1.0.0
).zip
is supported..zip
must contain all files that are described in how to prepare release.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>"
Prerequisites:
443
you need to specify the portYou don’t need to specify the protocol explicit.
module "my-module" {
source = "example.corp.com/<namespace>/<name>/<provider>"
version = "<version>"
}
terraform {
required_providers {
foo = {
source = "example.corp.com/<namespace>/<type>"
}
}
}
provider "foo" {
# Configuration options
}