Uptimeify Docs

Kunden-Token

Eine OpenTofu- oder Terraform-Konfiguration je Kunde, jede mit eigenem kundengebundenem API-Token und Provider-Alias.

API-Tokens gibt es in zwei Bereichen. Ein Organisations-Token verwaltet die ganze Organisation. Ein Kunden-Token erreicht nur die Kunden, an die es gebunden ist: genau richtig, wenn du Monitoring für mehrere Kunden betreibst. Details: Token-Bereiche.

Eine Konfiguration je Kunde

Gib jedem Kunden einen eigenen Provider-Alias und ein eigenes Kunden-Token. Ein Fehler im Code des einen Kunden erreicht die Monitore des anderen nicht.

variable "acme_token" {
  type      = string
  sensitive = true
}

provider "uptimeify" {
  alias     = "acme"
  api_token = var.acme_token
}

data "uptimeify_customer" "acme" {
  provider = uptimeify.acme
  name     = "ACME GmbH"
}

resource "uptimeify_website" "acme_shop" {
  provider    = uptimeify.acme
  customer_id = tonumber(data.uptimeify_customer.acme.id)
  name        = "ACME-Shop"
  url         = "https://shop.acme.example/"
}

Mit Terragrunt den provider-Block generieren und das Token je Unit übergeben, wie bei jedem anderen Provider.

Was ein Kunden-Token kann

Ein Kunden-Token verwaltet die Monitore seiner Kunden; Monitore, die es anlegt, sind immer self_service. Kunden anlegen kann es nicht. Auf einer organisationsweiten Ressource antwortet die API mit 403 customerScopedTokenForbidden; fehlt einem Token ein Scope, kommt 403 apiTokenScopeForbidden mit dem fehlenden Scope in data.requiredScope. Welcher Endpunkt welchen Scope braucht: Berechtigungen je Endpunkt.

Ressourcen, die beides können, etwa uptimeify_tag, brauchen mit einem Kunden-Token ein customer_id.

Auf dieser Seite