🧑💻 Terraform-провайдер для Tuna
Когда туннелей, доменов и шлюзов становится больше десятка, настраивать их кликами в личном кабинете уже неудобно: сложно повторить конфигурацию для второго окружения, непонятно, кто и когда что поменял. Поэтому мы выпустили Terraform-провайдер yuccastream/tuna — теперь инфраструктуру Tuna можно хранить в git рядом с остальным кодом, ревьюить в merge request'ах и применять через terraform apply.
terraform {
required_providers {
tuna = {
source = "yuccastream/tuna"
}
}
}
resource "tuna_domain" "preview" {
subdomain = "myapp-preview"
location = "ru"
}
Что можно описать
| Ресурс | Что описывает |
|---|---|
tuna_domain | Зарезервированный домен: поддомен встроенной зоны, своей зоны или собственный домен |
tuna_domain_zone | Доменная зона |
tuna_tls_certificate | TLS-сертификат для доменной зоны |
tuna_gateway | Шлюз с политикой трафика |
tuna_endpoint | TCP-порт |
tuna_ip_policy, tuna_ip_policy_rule | IP-политика и её правила |
tuna_public_key | Публичный SSH-ключ |
tuna_temporal_token | Временный токен для запуска туннелей |
Источник данных tuna_tunnels возвращает список туннелей аккаунта. Существующие ресурсы из личного кабинета можно подтянуть в state через terraform import.
Провайдер работает с Terraform 1.11+ и с OpenTofu. Приватный ключ TLS-сертификата передаётся через write-only атрибут и не попадает в state.
Пример: временные туннели для CI
Типичный сценарий — preview-окружения в CI. Terraform резервирует домен и выпускает временный токен с ограничениями, а CI-задача поднимает туннель с этим токеном. Основной API-ключ в CI при этом не попадает:
resource "tuna_temporal_token" "ci" {
description = "CI preview"
duration = "24h"
allow_http = true
allow_tcp = false
limit_by_active_tunnels = 5
limit_by_created_tunnels = 100
}
output "ci_tunnel_token" {
value = tuna_temporal_token.ci.token
sensitive = true
}
terraform apply
export TUNA_TOKEN="$(terraform output -raw ci_tunnel_token)"
tuna http 8080 --subdomain=myapp-preview
Пример: шлюз с политикой из файла
Шлюз — это домен с политикой трафика, который работает без запущенного клиента. Политика лежит в соседнем файле и меняется так же, через ревью:
resource "tuna_domain" "api" {
subdomain = "myapp-api"
location = "ru"
}
resource "tuna_gateway" "api" {
domain_id = tuna_domain.api.id
policy = file("${path.module}/policy.yaml")
}
Ещё несколько сценариев — своя доменная зона с wildcard-сертификатом, доступ по IP только из офиса — есть в документации.
API-ключи с правами по продуктам
Провайдеру нужен API-ключ, и отдавать ему полный доступ к аккаунту незачем. Поэтому вместе с провайдером API-ключи получили скоупы: ключ можно ограничить туннелями, мониторингом, секретами, бастионом, отчётами или командой — на чтение или на запись. Для Terraform достаточно tunnels:write.
Заодно мы закрыли для API-ключей всё, что может навредить аккаунту при утечке ключа:
- выпуск новых API-ключей, приглашения в команду и смена ролей участников;
- безопасность аккаунта: пароль, MFA, WebAuthn, токен туннелей, привязки провайдеров входа;
- оплата и подписка: способ оплаты, смена тарифа, получатели счетов, удаление команды;
- продление и завершение веб-сессий, пароли и mesh.
Всё это делается только из личного кабинета. Ключ, выпущенный без скоупов, получает доступ read_api — только на чтение.
С чего начать
- Выпустите в личном кабинете API-ключ со скоупом
tunnels:write. - Передайте его провайдеру через
export TUNA_API_KEY=.... - Опишите первый ресурс и выполните
terraform init && terraform apply.
Справочник по всем ресурсам и атрибутам — в Terraform Registry, обзор и сценарии — в нашей документации. Это первая версия провайдера: если вам не хватает какого-то ресурса, напишите нам — расширим.
Оставьте отзыв
Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.
Помощь
Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов: