TACACS+ TraceId documentation and update HLD#2358
Conversation
|
/azp run |
|
No pipelines are associated with this pull request. |
e394c2c to
8a29686
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
…uthorization Implements the HLD in sonic-net/SONiC#2358. Accepts a client-supplied `TraceId` env var via OpenSSH AcceptEnv, marks it readonly in the user's initial interactive bash, validates the value, and attaches it as a `TraceId=<value>` attribute on per-command TACACS+ authorization requests. Behavior is unchanged when TraceId is absent or invalid. How to verify it: - Build sonic-vs and SSH with `SendEnv TraceId` set to a valid value; confirm authorization requests include the TraceId attribute and that invalid/oversized values are silently dropped. - Run the bash_tacplus unit tests under src/tacacs/bash_tacplus/unittest/. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Introduces a High-Level Design for propagating a client-supplied SSH `TraceId` environment variable into TACACS+ command authorization requests issued by `bash_tacplus`. The `TraceId` provides a shared correlation key between external systems (access proxies, automation workflows, session recorders) and per-command TACACS+ authorization records, enabling end-to-end audit trail reconstruction without changing login behavior, TACACS+ server configuration, or command allow/deny semantics. The design accepts `TraceId` via standard OpenSSH `AcceptEnv` propagation, preserves it as a readonly variable in the user's initial interactive shell, validates the value, and attaches it as a `TraceId=<value>` attribute on command authorization requests. Behavior is unchanged when `TraceId` is absent or invalid. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Rod Persky <770327+Rod-Persky@users.noreply.github.com>
8a29686 to
c1eb65c
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
…uthorization Implements the HLD in sonic-net/SONiC#2358. Accepts a client-supplied `TraceId` env var via OpenSSH AcceptEnv, marks it readonly in the user's initial interactive bash, validates the value, and attaches it as a `TraceId=<value>` attribute on per-command TACACS+ authorization requests. Behavior is unchanged when TraceId is absent or invalid. How to verify it: - Build sonic-vs and SSH with `SendEnv TraceId` set to a valid value; confirm authorization requests include the TraceId attribute and that invalid/oversized values are silently dropped. - Run the bash_tacplus unit tests under src/tacacs/bash_tacplus/unittest/. Signed-off-by: Rod Persky <770327+Rod-Persky@users.noreply.github.com>
Signed-off-by: Rod Persky <770327+Rod-Persky@users.noreply.github.com>
|
/azp run |
|
No pipelines are associated with this pull request. |
|
Any plans to show some sort of indication in either CLI (or elsewhere) to indicate that we've TraceId implementation/support present. |
|
Hi Rod, One recommendation is to check if any testcases needs to be added into https://github.com/sonic-net/sonic-mgmt/tree/master/tests/tacacs Regards |
| This design adds one optional authorization attribute: | ||
|
|
||
| ```text | ||
| traceid=<trace-id> |
There was a problem hiding this comment.
What if we don't want to honor the trace-id in the SONiC switch, do we have a config option? I'm thinking from security standpoint.
There was a problem hiding this comment.
Hi @venkatmahalingam, I've added yang configuration which is exposed in redis that can be used to disable this feature. This also can be leveraged to identify the feature is available.
Signed-off-by: Rod Persky <770327+Rod-Persky@users.noreply.github.com>
|
/azp run |
|
No pipelines are associated with this pull request. |
|
@tirupatihemanth, regarding
I've added yang configuration which is exposed in redis that can be used to identify the feature is available and active. |
Signed-off-by: Rod Persky <770327+Rod-Persky@users.noreply.github.com>
|
/azp run |
|
No pipelines are associated with this pull request. |
Summary
Adds a High-Level Design (HLD) document at
doc/aaa/TACACS+ Trace ID.mddescribing how SONiC propagates a client-supplied SSHTraceIdenvironment variable into TACACS+ command authorization requests issued bybash_tacplus.Related implementation PR
[tacacs]: Add SSH TraceId authorization attribute(the code change implementing this HLD)[tacacs]: Add SSH TraceId authorization attribute supportMotivation
Operators routinely need to reconstruct what happened during a specific access session or automation workflow — not just what commands were observed on a device. Today, TACACS+ command authorization records identify the user and command but carry no end-to-end correlation value supplied by the client workflow. This results in disjoint audit trails between the device-side TACACS+ logs and external systems such as access proxies, session recorders, or automation runners.
TraceIdprovides a shared join key. An access proxy or automation system generates aTraceId, injects it into the SSH session, preserves the same value in its own logs, and SONiC copies the validated value into every TACACS+ command authorization request for that session. A TACACS+ server or downstream log pipeline can then correlate device command authorization records with external access-session, session-recording, incident-response, or automation-run records.Design overview
AcceptEnvis used to receiveTraceId; no new SSH client option is introduced.TraceIdreadonlyas a best-effort accidental-change guard (not a security boundary).bash_tacplusvalidates the value (length, character set) and either sends the exact value as atraceid=<value>AV pair, or omits the attribute entirely.TraceIdis absent or invalid, and for all non-authorization TACACS+ flows.Scope
In scope
TraceIdenvironment variable.readonlyin the initial interactive bash shell.traceid=<value>to TACACS+ command authorization requests only.Out of scope
ssh -o TraceId=<value>client option.Compatibility
TraceId.Document
doc/aaa/TACACS+ Trace ID.md— full HLD following the SONiC HLD template (sections 1-16).Type of change
This PR is documentation-only; the implementation lives in sonic-net/sonic-buildimage#27667.