# Приложения

Представьте: у вас есть внутренний сервис — админка, staging, Grafana, внутренний API — и вы хотите дать к нему доступ только нужным людям, из нужных стран, с подтверждением через корпоративный SSO. Приложения в Tuna решают именно эту задачу.

Приложения — это защищённый reverse proxy, который проверяет каждый входящий запрос: кто пользователь, как он аутентифицировался, откуда пришёл и имеет ли право видеть запрашиваемый путь.

![apps-main](/assets/images/main-90152e8c052b1e7bdcedf49998a8c57c.png)

Что можно сделать:

* закрыть любой веб-сервис авторизацией за пару минут, без изменений в коде самого сервиса;
* гранулярно разграничить доступ — например, `/admin/*` только для администраторов из России, а `/api/health` открыть без аутентификации;
* подключить корпоративный SSO (Google, Yandex, GitHub, GitLab, VK, любой OIDC-совместимый провайдер);
* требовать MFA или ручное одобрение администратора для чувствительных операций;
* опубликовать сервис без публичного IP через туннель — достаточно запустить одну команду;
* выдать машинный доступ через сервисные токены для CI/CD, мониторинга и автоматизации.

## Режимы работы

При создании приложения нужно выбрать, как Tuna будет доставлять трафик до вашего сервиса.

### Прокси

Tuna нода обращается к upstream напрямую по URL. Этот режим подходит, когда сервис уже доступен по сети — запущен в Kubernetes, в облачной VM или просто в той же сети, что и нода.

![Создание приложения в режиме прокси](/docs/img/apps/new_proxy_filled.png)

Можно указать несколько upstream-адресов — трафик будет распределяться по весам. Например, при весах 3 и 1 первый upstream получит 75% запросов, второй — 25%.

### Туннель

Бэкенд сам подключается к Tuna через клиент-агент. Идеальный вариант, когда сервис без публичного IP — за NAT, на dev-машине или в корпоративной сети.

![Создание приложения в режиме туннеля](/docs/img/apps/new_tunnel.png)

После создания приложения в режиме туннеля на странице деталей появится готовая команда:

![Команда для запуска туннеля](/docs/img/apps/tunnel_command.png)

```shell
tuna app <имя> --url=http://127.0.0.1:8080

```

Запустите её на машине с сервисом — клиент установит исходящее соединение к ноде, и приложение станет доступно через защищённый домен.

подсказка

Для быстрой проверки без реального бэкенда добавьте флаг `--hello-world` — Tuna запустит встроенный тестовый сервер.

## Создание приложения

подсказка

Этот раздел доступен **Основателю**, **Владельцам** и **Администраторам**.

Перейдите в раздел [Приложения](https://my.tuna.am/team_apps) и нажмите **+ Добавить приложение**.

| Поле          | Описание                                                     |
| ------------- | ------------------------------------------------------------ |
| **Имя**       | Уникальное имя внутри команды, будет использоваться в CLI    |
| **Режим**     | Прокси или Туннель                                           |
| **Upstreams** | Адреса бэкенда — только для режима Прокси                    |
| **Домен**     | Домен, через который приложение будет доступно пользователям |

## Основные параметры

После создания откроется страница деталей приложения с основными настройками.

![Основные параметры приложения](/docs/img/apps/edit_params.png)

* **Длительность сессии** — сколько живёт сессия после входа. По истечении пользователь проходит логин заново. По умолчанию — 24 часа.
* **Таймаут неактивности** — сессия сгорает, если пользователь не делал запросов дольше указанного времени. По умолчанию отключено.

## Провайдеры

Здесь выбираются способы входа в приложение. Можно комбинировать несколько вариантов — пользователь увидит их все на странице входа.

![Провайдеры авторизации](/docs/img/apps/providers_section.png)

* **Email OTP** — пользователь вводит email и получает одноразовый код. Удобно для внешних подрядчиков и разовых доступов.
* **Аккаунты tuna.am** — вход через личный аккаунт на tuna.am.
* **Провайдеры команды** — внешние Identity Provider (Google, Yandex, GitHub, GitLab, VK, любой OIDC), настроенные на странице [Провайдеры](https://my.tuna.am/team_identity_providers). Снимите галочку «Все провайдеры команды», чтобы выбрать конкретные.

![Список провайдеров команды](/docs/img/apps/identity_providers.png)

## Обзор

Блок **Обзор** на странице деталей наглядно визуализирует текущую конфигурацию: слева — кто может войти, в центре — через какие политики проходит запрос, справа — куда направляется трафик.

![Обзор приложения](/docs/img/apps/overview.png)

Это удобный способ одним взглядом убедиться, что всё настроено как задумано.

## Страница входа

Когда пользователь открывает защищённое приложение без активной сессии, он попадает на страницу входа. Набор кнопок формируется автоматически из подключённых провайдеров.

![Страница входа](/docs/img/apps/auth_page.png)

Если в команде настроены внешние провайдеры, каждый из них отображается отдельной кнопкой «Войти через ...»:

![Страница входа с провайдерами](/docs/img/apps/auth_page_providers.png)

к сведению

Внешний вид страницы входа можно кастомизировать — добавить логотип через [настройки приложения](https://tuna.am/docs/apps/settings.md).

## Пользовательский каталог

Участники команды видят все доступные им приложения в виде карточек на странице [Приложения](https://my.tuna.am/apps). Клик по карточке открывает приложение в новой вкладке.

В боковом меню пользователю также доступны [Запросы доступа](https://tuna.am/docs/apps/access_requests.md) и [Сессии](https://tuna.am/docs/apps/sessions.md) — для управления собственными запросами и активными сессиями.

## Аудит

Все действия с приложениями записываются в [аудит-лог](https://my.tuna.am/team_audit_events): создание и изменение приложений, входы пользователей, одобрения и отклонения запросов доступа, отзыв сессий. Каждое событие содержит детали — кто, когда, откуда и что именно произошло.

![Аудит-лог событий приложений](/docs/img/apps/audit_events.png)