* types: Declare all app_resources fields in the proto
Declare the eight reserved AppResource fields (paths, methods, where,
allow_encoded, allow_code, allow_reason, deny_code_hint,
deny_reason_hint) and the AppResourcesExpressions role condition, and
regenerate the proto stubs, the role CRDs, the Terraform schema and
docs, and the derived equality functions. Declaring the fields before
the fine-grained matcher merges lets every client of this version name
them, so a client that round-trips a role written by a newer auth
preserves the fields instead of silently dropping them on write-back,
which would widen the rule.
Tighten IsAllowAllOnly to require every declared field besides
allow_all to be unset. Without this, a rule such as {allow_all: true,
methods: [GET]} written by a newer auth would pass the check once the
fields are named, and this version would treat a method-restricted
rule as unrestricted.
Add GetAppResourcesExpressions to the Role interface, and read it in
decideMinimalV9 so the app agent denies a request governed by a
predicate it cannot evaluate. A predicate restricts the rules it
accompanies, so a role that pairs allow_all with one is not
unrestricted, and a deny-side predicate blocks another role's
allow_all the same way a deny-side rule does. Auth already treats both
as restricting when it downgrades a role for a pre-v9 client, so
without this the agent and auth disagree about the same role.
Strip AppResourcesExpressions in the v9-to-v8 downgrade alongside
AppResources, and reject it at write, so a role can neither reach a
pre-v9 client with the restriction silently removed nor be stored
while this version cannot enforce it.
* docs: List the declared app_resources fields
Honour the docs review on the app-resources reference page. A run of
inline code-style field names inside a sentence is hard to scan, so the
eight rejected `app_resources` fields become a list, and
`app_resources_expressions` gets its own sentence rather than trailing
the same run.
* buf: Trim the reserved-deletion except comment
Drop the two sentences explaining why buf's ignore lists cannot scope the
except. The rule name and the removal condition are what a reader needs
here, and the scoping attempts are recorded on the pull request.
* types: Reword the app_resources_expressions and Methods docs
Honour the review on the proto field comments. Drop "desugared" from
`AppResourcesExpressions`, which needs the RFD to gloss, and state the
relation between the two forms directly instead. Open `Methods` with the
plural, matching `Paths` on the row above.
Regenerate the proto stubs, the role CRDs, the Terraform schema and docs.
* Fix google.protobuf.Struct handling in the Kubernetes operator
This fixes a bug in the Kubernetes operator where nested fields in a
`google.protobuf.Struct` object would be silently pruned by the
validator. This matters to the `generic_oidc` join method where the
`must_match_fields` field (which accepts structured fields to match
against an incoming JWT) could get pruned and then silently ignored,
bypassing join rules.
Note that use of nested fields _usually_ results in an error, but only
in strict mode. It's the default now, but could still plausibly be
disabled causing silent loss of rules.
* Reword comment
* Add a pruning test beyond just schema validation
* operator: Add role v9 CRD kind
Register a TeleportRoleV9 kind with the Kubernetes operator so v9
roles can be managed declaratively. The reconciler reuses the shared
RoleV6 storage type with a version override, the same way the v7 and
v8 kinds do.
Generated changes:
make -C integrations/operator generate
* operator: Drop preserve-unknown on app_resources
Setting x-kubernetes-preserve-unknown-fields on app_resources rule items
relaxed the CRD schema to store fields it does not declare, so the operator
could reject them on decode. That keeps invalid data in cluster state and is
hard to walk back once shipped, even after Kubernetes field validation
improves. Rely on the structural schema and server-side field validation to
reject unknown fields at the API server instead, and drop the tests that
asserted the operator-side rejection.
* operator: Match the reconciler factory signature
The scoped operator work added an OperatorMetadata parameter to
ReconcilerFactory and updated every existing role reconciler. The v9
reconciler was written before that change, so master and this branch each
compile alone but not once merged, and the merge queue rejects the result.
Take the parameter and ignore it, as the v6 to v8 reconcilers do.
This commit implements the following changes:
- add a kubernetes state in which the operator can store its ID
- move ownership checks and label setting to the adapter interface
- add the scoped resource with label adapter
- add operator metadata and propagate it to scoped reconcilers
- make scoped adapters check the operator id label when the resource is
scoped
- make scoped adapters set provenance labels when the resource is
scoped
- fix the controller tests that were no longer able to infer the
generics type since `api/types` was not directly imported anymore
- make the operator reject reconciling a resource whose scope does not
match its own
- enable and fix scoped resource tests:
- use the same test scope everythere
- set the test scope in the operator metadata
- generate and use the operator ID
1) Allow make gen-tfschema to run offline by removing -u from go list
2) Prevent stale codgen by deleting previously generated code prior to
executing go run ./gen/main.go
As a result of 2, some files that don't have an existing payload registered
in gen/main.go have been removed.
* types: Add minimal role v9 with app default-deny
Add role resource version v9. A v9 role denies all access to HTTP apps
by default: when it grants an app via `app_labels` or
`app_labels_expression`, every HTTP request is denied unless an
allow-side `app_resources` rule permits it (RFD 0303).
Add `app_resources` to a role's `spec.allow` (not `spec.deny`), rules
controlling access to an app's resources on each HTTP request. For now
a rule holds one field, `allow_all`, which grants unrestricted access,
equivalent to v8, and must be the only rule. Reserve field numbers for
the fine-grained fields (`paths`, `methods`, `where`, audit codes) so
later releases add them without renumbering. Bump the role version in
an N.0.0 release: the breaking default-deny aims to ship in Teleport
v19.0.0.
Reject at write time any `app_resources` use on pre-v9 roles, under
deny, in a rule that does not set `allow_all`, or in a rule next to
another rule.
Serve v9 roles to clients older than 19.0.0 as v8 copies: the auth
server strips `app_resources` and marks the copy with the
`teleport.internal/downgraded` label. The stored role stays v9; only
what goes over the wire changes. The downgrade fails closed: unless a
rule sets `allow_all` (exactly v8 access, lossless), the copy also
loses its allow `app_labels` and `app_labels_expression`, so an older
agent denies the app entirely instead of serving it unrestricted.
Enforce the default-deny in the app agent's plain-HTTP path; TCP, MCP,
cloud, and LLM apps are excluded. When v8 and v9 roles grant the same
app, drop the v8 roles from the decision so they cannot re-open
unrestricted access, and log a warning once.
Bundle the Terraform provider update so v9 roles can be managed as
code starting with v19.0.0. The operator v9 CRD kind follows
separately.
Generated changes:
make grpc/host
make derive
make -C integrations/terraform docs
make -C integrations/operator generate
* auth: Downgrade roles from GetCurrentUserRoles
Run every role streamed by GetCurrentUserRoles through
maybeDowngradeRole before sending, matching GetRole, GetRoles,
ListRoles, and the watch stream. Without it, a pre-19 client asking a
remote cluster for its mapped roles receives a v9 role with allow
app_labels intact and no app_resources enforcement it understands, so
client-side access checks treat a default-deny role as granting full
app access. The change also applies the pre-existing v8-to-v7
downgrade on this surface, which previously served v8 roles to v17
clients unchanged.
* terraform: Exclude deny-side app_resources from schema
Drop `app_resources` from the Terraform role schema's deny block, as
the server rejects any deny-side `app_resources` at write time and
RFD 0303 keeps the rules allow-only so that they fail closed. With the
field gone from the schema, Terraform rejects a deny-side rule at plan
time instead of leaving it to the server's write-time check. Follow the
existing `RoleV6.Spec.Deny.Namespaces` exclusion.
Generated changes:
make -C integrations/terraform docs
* docs: Split role versions into per-version headings
Break the Role versions section into one H4 per role version so
readers can jump straight to the version they care about. Move the
SAML IdP note under the v8 heading, since it describes a v8 change,
and keep the kubernetes_resources defaults table as its own H4 at
the end. Fix a mismatched backtick around `v5` in the moved
session-joining paragraph.
* app: Warn when version skew denies a v9 request
When the minimal v9 check denies a request because the user's roles
carry `app_resources` rules or role versions this Teleport version
does not implement, the app agent previously answered 403 without any
log line. In a mixed-version cluster an operator saw denied requests
with no explanation that the deny came from a version mismatch rather
than from an intended default-deny role.
Track the condition as `versionSkew` on `minimalV9Decision`:
deny-side rules, allow rules beyond a single pure `allow_all`, or a
role version above v9. When such a deny fires, log one warning per
user and app through the existing `v9WarnOnce` mechanism, telling the
operator to upgrade the app agent. An intended default-deny, a v9 role
without app rules, stays quiet. A follow-up PR adds a minimal audit
event for the same denials.
* app: Deny apps a downgraded v9 role restricted
A v9 role that restricts app access downgrades to v8 for a pre-v19 agent
that cannot enforce the restriction. Clearing the role's allow app labels
alone would only stop that role granting the apps; another v8 role the user
holds could still grant them, so the restriction would not hold on the old
agent. Move the role's allow app selector to the deny side instead, so no
other role grants the apps this role restricted. The deny is at least as
strict as the v9 restriction and never grants more.
If the role already denies apps by label, there is no room to merge a
second label map, so fall back to a wildcard deny and log it rather than
drop the existing deny.
* docs: Correct v9 downgrade mixed-version guidance
Describe the deny-side downgrade the code actually performs. Without
`allow_all`, the v8 copy moves the allow app selector to the deny side
rather than dropping it, so deny rules override allow rules across a user's
roles and a separate v8-or-older role can no longer reopen the app on
pre-v19 agents. Note that the moved selector denies conservatively and can
block more apps than the v9 role allowed in a mixed-version cluster.
* role: Deny v9 app access for unknown JSON fields
Empty any v9 allow app_resources rule whose stored JSON carried a field
this version does not recognize, so a rule written by a newer version cannot
read as more permissive than intended. An unrecognized field already denies
on the other surfaces: proto reads keep it in XXX_unrecognized so
IsAllowAllOnly rejects it, and writes reject it at validation. JSON unmarshal
drops unknown fields silently, so this re-scans the raw bytes on read. The
known field set is derived from the AppResource message, so a new proto field
extends it automatically. The result is a single rule across every surface,
an unrecognized field grants nothing, worst case over-deny.
* app: Deny app access from roles newer than v9
A role from a version above v9 may carry restrictions this agent cannot
evaluate, so treat it as deny even when its known fields form a plain
allow_all. Previously such a role set both versionSkew and allowed, and
enforceMinimalV9 returns early on allowed, so the request was forwarded and
the skew warning never fired.
* auth: Explain the greedy deny in the v9 downgrade
The downgrade moves a v9 role's allow app selector to the deny side, which
looks like it could clobber an existing deny expression. Record why it
cannot, since deny matches on either selector, and why label maps fall back
to a wildcard where expressions compose with an or.
* api: Guard the AppResource field set with a test
IsAllowAllOnly decides whether a rule is unrestricted by checking that
allow_all is set and no unknown bytes arrived over the wire. A field added
in tree, once one of the reserved numbers is unreserved, would restrict the
rule without making that check return false. Pin the field set so such an
addition fails the test, and name the checks to re-evaluate next to the
reserved numbers in the proto.
* app: Bound the v9 warning deduplication cache
The v9 enforcement warnings fire once per warning kind, user, and app, and
the sync.Map holding those keys never dropped an entry, so a long-running
app agent serving many users and apps grew it for the life of the process.
Hold the keys in a fixed-size LRU instead. Evicting the least recently
warned entry repeats its warning, which is the better failure mode.
* role: Address review feedback
Reword the checkAppResources godoc so the api module does not reference
lib/services. Move the unknown-field check for allow app_resources rules
from integrations/lib/tctl into lib/services next to the other role
unmarshal handling, and derive its known field set from the AppResource
message instead of hardcoding allow_all, so unreserving a proto field
extends it without a second edit. Replace the package-level
preV9RoleVersions slice with roleVersionPredatesV9, a function with a
switch, so nothing mutable sits at package scope.
* role: Address agent review feedback
Reword the `decideMinimalV9` godoc so only a v9 role can allow; a
version above v9 always denies. Drop the `AppResource` message summary
sentence that misstated the reserved field numbers as path, method, and
where rules; fields 6 to 9 hold the audit and deny-hint fields. Reword
the `TestAppResourceFields` comment so the api module does not point
at `lib/services`. Give `v10Grants` an `allow_all` rule so the
above-v9 test case fails if a newer-version role with a plain
`allow_all` rule ever allows again. Add a downgrade subtest for the
deny-expression OR-merge, which no test executed, and a `lib/services`
table test for `CheckAppResourcesKnownFields`, which was only
exercised from the integrations module after its move.
* role: Compact review-feedback additions
Tighten the previous commit's additions, partly to keep the PR under
5,000 added lines. Compact the `CheckAppResourcesKnownFields` table
test into direct assertions, flatten the allowed branch in
`decideMinimalV9`, iterate the `AppResource` fields with
`reflect.TypeFor`, drop the slice alias in
`denyAppAccessForUnknownFields`, and shorten two test comments and a
wrapped constructor call. No behavior change.
* role: Reuse access checking for v9 app decisions
The v9 default-deny check needs to know which individual role grants an
app. `roleGrantsApp` answered that by repeating the namespace and label
stages of `RoleSet` access checking inside `lib/srv/app`, where a second
implementation can drift from the original. Replace it with
`services.RoleGrantsResource`, which delegates to `RoleSet.checkAccess`
and follows the existing single-role idiom in
`lib/services/access_checker.go`.
Delegating changes one case. `resourceRequiresLabelMatching` exempts the
Identity Center app subkind from app label matching, so `checkAccess`
treats every role as granting such an app and v9 denies requests that
`roleGrantsApp` allowed. Add `isPlainHTTPApp` to skip enforcement for
that subkind alongside the cloud and LLM types, which is the scope v9 is
documented to cover, and log once per user and app when an app reaches
the check that should have been routed elsewhere. Drop the unused error
return from `decideMinimalV9`.
Remove `CheckAppResourcesKnownFields`. The property it enforced, that a
role never stores an `app_resources` rule with a field this version does
not understand, already holds on the write path, where `UnmarshalRole`
empties such a rule and `validateAppResources` then rejects it for no
longer setting `allow_all` alone. Its only caller was a test helper for
the access plugins, so assert the write path directly instead.
Describe `validateAppResources` by the property it guarantees rather than
by each check it runs, so the godoc does not drift as the checks change.
Explain why the role stream downgrades per client version, and say
explicitly that both versions in the `maybeDowngradeRole` ordering
comment are the client's, which read ambiguously as the server's. Cut the
role v9 reference section to the field it introduces and a link, and move
the rules, the mixed-version role behavior, and the agent upgrade it
requires to a new Application Resources reference page.
* docs: Use a defined tag on the app resources page
The application-access tag is not in the docs tags vocabulary, so the
docs build rejected the new page. Use privileged-access, which the
sibling roles reference page already carries.
* terraform: Regenerate the schema with protoc-gen-terraform v4
Master upgraded the generator to v4.0.0, which marks list-nested
attributes computed and preserves unknown elements by index. Regenerate
so the app_resources attributes match what the pinned generator emits.
* Enable managed updates by default
* Expose ECS task Teleport configuration
* Make RDS modification permissions opt-in
* Standardize Terraform format expressions
* Update default IAM token name
* Update discovery module RDS policy actions
These permisisons are necessary to support the web UI flow which has to list
VPCs, subnets, and security groups.
* Eliminate teleport_discovery_config_name local var
It was used in only one place.
* Fix nonsensitive cast in token name output
* fix container-service example
* fix docs lint
* add configurable automatic review reasons
* generate CRD and terraform schemas
* document reason field in automatic review docs
* add validation for automatic review reason field
* Re-run "make grpc"
* remove unnecessary variable copy
* simplify a test
* Re run make tf integration docs
* Bump protoc-gen-terraform v4.0.0-dev.1
* make gen-tfschema
* Temporarily skip broken tests
* [terraform] exclude `nonce` attribute (#67075)
* [terraform] exclude `metadata.revision` attribute (#67084)
* [terraform] set `role.spec.options.record_session` as a computed attribute (#67094)
* Enable SessionSummaries entitlement for tests
* [terraform] Update auth_preference protoc-gen-terraform config (#67154)
* Update protoc-gen-terraform-teleport.yaml
The following attributes are marked as computed:
- AuthPreferenceV2.Spec.IDP
- AuthPreferenceV2.Spec.IDP.SAML
- AuthPreferenceV2.Spec.Okta
The following attributes are no longer marked as required:
- AuthPreferenceV2.Metadata.Name
* [terraform] Fix custom attribute schema (#67345)
* Update custom schema attributes
Ensure constraints including `Computed` and `PlanModifiers` are
propagated to final attribute struct.
* Update custom attribute CopyTo logic
- CopyTo now clears the `Null` and `Unknown` fields.
- CopyTo now replaces stale values within lists/maps.
* Update custom attribute CopyFrom logic
- CopyFrom now sets nil object when value is `Null` or `Unknown`.
* [terraform] Remove metadata.expires as a computed_field (#67441)
Prior to `GenSchemaTimestamp` changes, none of the timestamp attributes
were actually computed because the `Computed` field was being discard.
Now that the custom attribute schema has been fixed, the provider
complains that the `plan was not empty` with a perpetual drift when
Teleport does not provide a default value for `metadata.expires`. To
resolve this issue, all `metadata.expires` attributes have been removed
from the list of `computed_fields`.
Additionally, `scoped_role.metadata.expires` and
`scoped_role_assignment.metadata.expires` are not supported configuration.
They are now `excluded_fields`.
* [terraform] fix plural resource update method (#67478)
* [terraform] Implement resource-level ModifyPlan (#67294)
* [terraform] Update cluster_networking_config protoc-gen-terraform config (#67216)
* [terraform] Exclude created_at and created_by (#67621)
* Bump protoc-gen-terraform v4.0.0-dev.2
* make gen-tfschema
* [terraform] Update protoc-gen-terraform-accesslist.yaml (#67139)
* Update protoc-gen-terraform-accesslist.yaml
The following attributes are marked as computed:
- access_list.spec.audit
- access_list.spec.audit.notifications
- access_list.spec.audit.notifications.start
- access_list.spec.audit.recurrence
- access_list.spec.audit.grants
- access_list.spec.audit.owner_grants
- access_list.spec.audit.membership_requires
- access_list.spec.audit.ownership_requires
The following attributes are marked as required:
- access_list.spec.title
The following attributes are marked as excluded:
- access_list.spec.audit.next_audit_date
* [terraform] Implement ModifyPlan for login_rule (#67894)
* Bump protoc-gen-terraform v4.0.0-dev.3
* [terraform] preserve unknown values during TF plan (#68405)
* Update templates to use preserve unknown
* Update tfschema/custom_types.go
CopyToBoolOption, CopyToLabels, CopyToTraits, and CopyToStrings now
accept the preserveUnknown flag.
* Update resource153/custom_types.go
CopyToTimestamp, CopyToDuration, and CopyToLabel now accept the
preserveUnknown flag.
* Update summarizer/v1/custom_types.go
CopyToClassifierActionMode, and CopyToRiskLevel, now accept the
preserveUnknown flag.
* Exclude access_list_member fields
The following fields are managed by Teleport:
- member.spec.added_by
- member.spec.joined
- member.spec.name
* teleport_bot requires teleport.dev/origin label
* Fix outdated trusted_cluster example
* Exclude teleport_workload_cluster.status
* Compute teleport_discovery_config attributes
- spec.aws.install is now computed
- spec.aws.ssm is now computed
* Fix teleport_trusted_device terraform type
* Set `role.spec.options.idp` as a computed field
The default value for v7 roles is `idp.saml.enabled = true`
* Re-enable skipped tests
* Bump protoc-gen-terraform v4.0.0
* Update generated code for scopes resources
Tim Buckley