mirror of https://github.com/BerriAI/litellm.git synced 2026-09-07 08:26:10 +00:00

feat(terraform): vendor terraform-provider-litellm as source of truth with endpoint drift CI (#32241 )

* feat(terraform): vendor terraform-provider-litellm as source of truth with endpoint drift CI

* fix(terraform): address review feedback on vendored provider

Replace deprecated io/ioutil with io. Remove the unused org/team CRUD
client methods so the endpoint audit only tracks live call sites
(54 -> 46). Redact request/response logs by parsing the JSON and
recursively masking sensitive fields, which fixes the nested-object
leak in the old credential_values regex, with a regex fallback for
non-JSON payloads; covered by new unit tests. Docs: stop showing
api_key inside vector store litellm_params and document that Sensitive
attributes still persist in plaintext state, recommending
litellm_credential_name and an encrypted state backend.

* fix(terraform): stop persisting server-returned litellm_params into vector store state

The vector store Read wrote litellm_params straight back from the API
response into state. The proxy redacts secrets in those responses, so
the readback overwrote user config with redaction sentinels and caused
perpetual diffs, and against a server that returns raw values it would
persist secrets into a non-Sensitive attribute. Read now preserves the
config value like the credential and model resources do, litellm_params
is marked Sensitive, and a regression test pins that a server-returned
api_key never lands in state

* fix(terraform): send role on team member update and stop persisting server env into MCP state

The team member update payload omitted role, and the proxy leaves role
unchanged when the field is absent, so a role downgrade reported as
applied by Terraform never took effect on the proxy. The update now
always sends the configured role (the attribute is Required).

The MCP server resource wrote env straight back from API responses
into a non-Sensitive attribute, pulling admin-visible secrets into
state and, for sanitized responses, blanking user config. Read now
preserves the config value, env is marked Sensitive, and the docs warn
against passing secrets via args. Regression tests cover both fixes
and fail against the previous behavior.

2026-07-07 09:16:59 -07:00

3.6 KiB

Raw Permalink Blame History

Resource: litellm_team_member_add

Add multiple members to a team with a single resource. This resource efficiently manages team members by using the appropriate API endpoints for each operation:

Adding new members: Uses /team/member_add endpoint
Updating existing members: Uses /team/member_update endpoint (preserves member identity)
Removing members: Uses /team/member_delete endpoint

When you modify an existing team member's attributes (like role), the resource will update the member in-place rather than deleting and re-adding them.

Example Usage

Basic Usage

resource "litellm_team_member_add" "example" {
  team_id = "team-123"
  
  member {
    user_id = "user-456"
    role    = "admin"
  }

  member {
    user_email = "user@example.com"
    role       = "user"
  }

  max_budget_in_team = 100.0
}

Complete Team Setup with Members

# First create a team
resource "litellm_team" "development" {
  team_alias = "development-team"
  max_budget = 500.0
  models     = ["gpt-4", "gpt-3.5-turbo"]
  
  team_member_permissions = [
    "create_key",
    "view_spend"
  ]
}

# Add members to the team
resource "litellm_team_member_add" "dev_team_members" {
  team_id = litellm_team.development.id
  
  # Team lead with admin role
  member {
    user_email = "team-lead@company.com"
    role       = "admin"
  }
  
  # Regular developers
  member {
    user_email = "developer1@company.com"
    role       = "user"
  }
  
  member {
    user_email = "developer2@company.com"
    role       = "user"
  }
  
  member {
    user_id = "existing-user-123"
    role    = "user"
  }
  
  # Budget per member
  max_budget_in_team = 100.0
}

Dynamic Members Using Locals

locals {
  team_members = [
    {
      user_id  = "user-123"
      role     = "admin"
    },
    {
      user_email = "developer1@company.com"
      role      = "user"
    },
    {
      user_email = "developer2@company.com"
      role      = "user"
    }
  ]
}

resource "litellm_team_member_add" "dynamic_example" {
  team_id = "team-456"
  
  dynamic "member" {
    for_each = local.team_members
    content {
      user_id    = lookup(member.value, "user_id", null)
      user_email = lookup(member.value, "user_email", null)
      role       = member.value.role
    }
  }

  max_budget_in_team = 200.0
}

Budget Update Example

# This example demonstrates how budget updates work correctly
resource "litellm_team_member_add" "budget_example" {
  team_id = litellm_team.example.id
  
  # Initial budget of $100 per member
  max_budget_in_team = 100.0
  
  member {
    user_email = "user1@example.com"
    role       = "admin"
  }
  
  member {
    user_email = "user2@example.com"
    role       = "user"
  }
  
  member {
    user_id = "user123"
    role    = "user"
  }
}

# To update the budget:
# 1. Change max_budget_in_team from 100.0 to 120.0
# 2. Run terraform plan - it will show the budget change
# 3. Run terraform apply - all existing members will be updated with the new budget

Argument Reference

team_id - (Required) The ID of the team to add members to.
member - (Required) One or more member blocks defining team members. Each block supports:
- user_id - (Optional) The ID of the user to add to the team.
- user_email - (Optional) The email of the user to add to the team.
- role - (Required) The role of the user in the team. Must be one of: "admin" or "user".
max_budget_in_team - (Optional) The maximum budget allocated for the team members.

Import

Team members can be imported using a composite ID of the team ID and user ID:

terraform import litellm_team_member_add.example team-123:user-456

3.6 KiB Raw Permalink Blame History