mirror of
https://github.com/gravitational/teleport.git
synced 2026-10-12 02:15:01 +00:00
Julia Ogris
2a05d3edfe
* 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.