* support `where` RBAC on application session recordings
application session recordings are backed by AppSessionChunk events, but
those events were never wired into the session recording RBAC path, so
`where` clauses on `kind: session` rules could not match them.
Fixes https://github.com/gravitational/teleport/issues/67775
Signed-off-by: Tiago Silva <tiago.silva@goteleport.com>
* fix unit test
* handle feedback
---------
Signed-off-by: Tiago Silva <tiago.silva@goteleport.com>
* proto: add UsageApp to IssueScopedBotCertsRequest proto
* issuance: add UsageApp support to IssueScopedBotCerts
Implement the server-side handling for the UsageApp usage in
IssueScopedBotCerts. When a scoped bot requests app-routed certificates,
the service now:
- Validates the requested app scope against the caller's scope pin
- Resolves the app via RangeApplicationServersWithName, ensuring it
exists in the exact scope claimed
- Rejects Identity Center account apps (not routable, no scoped role
support for account assignments)
- Creates a scoped app session via CreateAppSessionFromReq
- Annotates the output certificate with app routing and session info
* issuance: ensure field error messages are consistent
* issuance: remove unnecessay TestIssueScopedBotCerts_UsageApp_ScopeHierarchy test cases
These tests were a left over when previous code was fetching and
validating exact scope matching.
Since that code was removed, I've removed the exact match cases and
moved the other 2 up to the TestIssueScopedBotCerts_UsageApp tests.
* linter: Fix imports
* tests: Use t.Context in internal t.Run calls
* issuance: Validate the PublicAddr is present in UsageApp
* tests: convert scoped IssueScopedBotCerts failure tests for UsageApp to table tests
* issuance: UsageApp validates the PublicAddr against ScopedAppPublicAddrValid
* test: add explicit test in IssueScopedBotCerts to check scope presence
Exercise `maybeDowngradeRoleVersionToV8` with property tests so the
guarantee holds for arbitrary roles, not just the handful of hand-written
roles the example test checks. The downgrade is a security control. A
pre-v19 agent cannot enforce a v9 role's `app_resources` restriction, so
the downgraded v8 copy must move the role's allow app selector to the
deny side and never leave one of its own apps reachable. The
allow-to-deny move branches on whether a deny selector already exists,
which is where a fail-open bug would go unnoticed.
Generate random allow and deny label selectors and candidate apps, then
assert three properties. Every app the role allowed before the downgrade
is denied after. Every app it already denied stays denied. The input role
comes back unmodified, because the caller passes the cache's shared role.
Add apps matching each selector, and the deny expression, to every
generated set, because random apps match a keyed selector in under a
tenth of draws and the assertion body is otherwise skipped. Draw globs as
selector values, since `services.MatchLabels` matches them as regular
expressions and a downgrade that dropped them would serve a copy denying
nothing.
Cover the AND-to-OR downgrade in a second property, which adds a label
expression on each side. An allow rule needs both `app_labels` and
`app_labels_expression` to match while a deny rule needs either, so
moving them across separately denies more apps than the role allowed. Add
an example test for that over-deny, where a wildcard label set moved to
the deny side blocks apps outside the allow rule.
Use `pgregory.net/rapid`, already a direct dependency of this branch.
This PR adds audit queue observability to tctl. It allows you to view
the audit queue depth and also sort records based on number of events in
each queue.
In preparation for 19.0.0 this removes all references
to legacy or broken record keys. The background key
conversion will have already converted all legacy or broken
keys thus allowing the removal of the migration and the key types.
* Add audit events for approving & denying an `EnrollPairing`
* Add web changes
* Drop `device.enroll_pairing.approve` from `eventGroupTypes`
* "not approved" -> "denied"
* Update wording around `device.enroll_pairing.approve` emitted on failure
While working on the RPC handler implementation, I realized that
`TV011W` is not emitted on MFA failures. This commit updates the godoc
and the fixture accordingly.
* Update `deny` audit event wording around expiry
In a typical scenario there will be no one to observe expiry, so this
event won't be emitted on enroll pairing expiry. I'll update the RFD
accordingly soon. For now just putting this here since I have no other
outstanding OSS PRs.
* Remove no longer necessary TODO comment
"Retryability" will be implemented one level above the storage layer, in
the RPC handler, so the comment here is no longer necessary.
* Remove `error` field from `device.enroll_pairing.deny`
Now that it's only going to be used for an explicit user denial, there's
no need to carry the `error` field.
* Add tenant_id and client_id fields to Azure VM discovery tasks and update related handling
* Update lib/usertasks/descriptions/azure-vm-subscription-list-denied.md
Co-authored-by: alex hemard <alex.hemard@goteleport.com>
---------
Co-authored-by: alex hemard <alex.hemard@goteleport.com>
* 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.
Caching has become an integral part in functionality provided
by teleport. Allowing users to disable the cache was never something
that was a recomended configuration - it was predominately used
as a stopgap to address an outage. However, over time the cache
has become more stable and the need to bypass it should never
arise.
Additionally, this toggle causes several architectural difficulties
that increase complexity and maintainability of teleport. By always
enforcing that the cache is on, we can eventually separate the gRPC,
backend, and caching layers - a frequent developer experience nightmare.
Moving to a world where the cache is always guaranteed to be present
and available we will be able to remove layers of abstraction and
increase performance.
We do still honor `teleport.cache.max_backoff`. While it was tempting
to remove all teleport.cache knobs, it seemed that still allowing users
to control the backoff interval could alleviate any caching related
issues that lead to or are contributing to an outage. This seemed rather
important to still offer now that the ability to disable caching no
longer exists.
* kube: add reusable-MFA requester for tsh proxy kube fan-out
* Regenerate protos
* update kube_proxy.go
* pass client explicitly
* change return type
* add cert issuer
* add tests
* defer auth client close
* replace fallback bool with requester state
* rename concurrency env var to TELEPORT_UNSTABLE_
* rename receiver
* apply review style suggestions
* add integration test for kube cert reissuer
* add distinct Teleport clusters issuer test
* slice mfaOn once after first issuance
* Add kubeClusterGroup for bounded cluster fan-outs
* Add ReissueParams.FailOnExpiredReusableMFAResponse
Add ReissueParams.FailOnExpiredReusableMFAResponse
* Single-flight MFA ceremonies in kube cert issuer
* Extend kube cert issuer tests
* Fix kube proxy test
* Add clusterConn for shared cluster connections
update conn test
* Rework kubeClusterGroup API and add tests
update group test
* Add reusableMFA for shared MFA ceremony state
* Fix comment
* Address review feedback
* Add MFA challenge scope for kube local proxy multi
* Document nil mfaCheck semantics on IssueCert
* Skip NotFound key rings explicitly in loadKubeKeyRings
* Update comment
* Drop redundant requester check before Capture
* Rename test to RootAndLeafTeleportClusters
* Restore ephemeral kubeconfig before cert issuance in kube proxy reissuer
* Add lingering to cluster conn
* Fix misspelling in cluster conn test
* Clarify linger wording in cluster conn test
* Check positive condition in cluster conn close timer
* Fix cluster client test missed by MFAChecker rename in master merge
* Fail the issuance when taking the ceremony lock fails
* Detect the masked MFA reuse rejection of old auth servers
* Test kubeconfig restore on a failed reissue in kube proxy
* Clone credential maps handed out by the in-memory key store
* Invalidate the cluster conn on errors a relogin can resolve
* Scope MFA fallback by rejection confidence
* Fix scope name in issuer doc comment
* Drop test-only FallbackActive method
* Load kube key rings through the keystore seam
* Share the reissue mutex across reissuer closures
* Remove the kube cert reissuer integration test
* skip rewriting /etc/resolver files when dns config is unchanged on macOS
* change resolver drift detection from size to content checks
* fix some nits
* treat unreadable resolver files as unmanaged instead of failing
This change adds the error handling for Retry logic
in pgbk to also handle `pgerrcode.DuplicateTable`.
When two (or more) auth instances both try to create/setup
the same schema at nearly the same time, even with `IF NOT EXISTS`,
Postgres can still return `duplicate_table` (`42P07`) in a concurrent
create race. Retrying lets the losing instance re-check after the
winning instance finishes creating the table.
* Integrate Windows VM discovery in to Azure watcher
* Address comments
* Rebase and address feedback
* Filter scale set by resource group
* Fix test
* Fixes and tests
* Adapt to whole sub list
* Add godoc
* Rebase
Peter Willis