Skip to content

docs: list what the audit log records, and name EXTENDDB_PASSWORD for manage - #842

Open
LeeroyHannigan wants to merge 1 commit into
mainfrom
docs/audit-log-and-manage-password
Open

LeeroyHannigan wants to merge 1 commit into
mainfrom
docs/audit-log-and-manage-password

Conversation

@LeeroyHannigan

Copy link
Copy Markdown
Collaborator

What

  • docs/getting-started.md section 9 now lists the operations that write audit entries, as the security model does (Operational Security, Logging):
    • extenddb::audit::manage: DeleteAdmin, user and role tag changes, and AssumeRole, both granted and refused by the role's trust policy.
    • extenddb::audit::settings: each settings change made through the management API (PUT /management/settings/{key}).
  • Section 9 also says these things:
    • extenddb settings set changes the catalog without the server and prints its entry on its own standard output. So the server writes no audit entry for that change.
    • The audit log does not record other management changes. These include creating admin users, group membership and permissions boundary changes, password changes and credential import. They also include creating and deleting accounts, IAM users, groups, roles, access keys and policies.
    • The server writes no audit entry while the log level is error, or while logging.level turns the audit targets off.
    • The entries go to syslog when the server runs as a daemon, and to stderr with --foreground. The section gives the Linux, macOS and Docker Compose commands.
  • Section 7 no longer says that the server logs every credential import.
  • docs/manuals/05-admin-guide.md and docs/manuals/10-security-model.md say the same, and no longer say that all logging goes to syslog.
  • docs/getting-started.md section 7, the security note after the import-access-key example, and docs/manuals/10-security-model.md (Credential Handling) now tell extenddb manage users to set EXTENDDB_PASSWORD. Before, they named EXTENDDB_ADMIN_PASSWORD. The notes set it with read -rs, which keeps the password out of shell history. They also say that --admin-password, --new-password, --user-password and --secret-access-key have no environment variable.

Why

Section 9 said that every management and settings operation goes to the audit log. The server writes audit entries for 4 kinds of change only. An operator who reads the old text expects a record of each key, user and policy change, and the log does not have one.

extenddb init reads EXTENDDB_ADMIN_PASSWORD for the password of the first admin. extenddb manage reads EXTENDDB_PASSWORD when --password is not given (crates/app/src/manage_http.rs). A user who followed the old text and left out --password got No password provided. Use --password VALUE or set EXTENDDB_PASSWORD.

Testing done

  • I compared each list with the extenddb::audit log calls on main: admin.rs, assume_role.rs, iam_user.rs, iam_role.rs and ops_settings.rs in crates/server/src/management/, and crates/app/src/cmd_settings.rs. The console writes no audit entries and has no route for these changes.
  • I read where extenddb settings set writes its log (run_interactive in crates/app/src/lib.rs installs a subscriber that writes to standard output), and the server's log filter (crates/server/src/serve.rs and crates/server/src/workers.rs).
  • I read the password lookup in crates/app/src/manage_http.rs, the flags in crates/app/src/manage_types.rs, and the variable that crates/app/src/cmd_init.rs reads.
  • The change is docs only.

Checklist

  • I have read CONTRIBUTING.md
  • All tests pass (cargo test --workspace)
  • Code is formatted (cargo fmt --check)
  • Clippy is clean (cargo clippy -- -W clippy::pedantic)
  • I have added or updated tests for new functionality
  • I have updated documentation if behavior changed
  • Breaking changes are noted below (if any)
  • If this changes the wire protocol, Storage trait, auth model, on-disk
    format, or public CLI surface, an RFC has been accepted or is linked
    below. Otherwise, an ADR captures the decision (link below).

ADR / RFC: n/a. The change makes the docs match the code.

Merging with #228

#228 also edits the Credential Handling list in docs/manuals/10-security-model.md, on the line after the line that this PR changes. The PR that merges second keeps both lines.


By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache License 2.0 and I agree to the Developer Certificate of
Origin (DCO). See CONTRIBUTING.md for details.

… manage

getting-started.md said that every management and settings operation
goes to the audit log. Its list included changes to accounts, users,
groups, roles, policies and access keys. Section 7 said that the server
logs every credential import. The server writes audit entries only for
DeleteAdmin, user and role tag changes, AssumeRole (granted, and refused
by the role's trust policy) and settings changes made through the
management API. extenddb settings set changes the catalog without the
server and prints its entry on its own standard output, so the server
writes no audit entry for it.

Section 9 now says this and names the changes that are not
audit-logged. It also says that the server writes no entry while the
log level is error or the log filter turns the audit targets off, and
gives the macOS and Docker Compose commands. The admin guide and the
security model say the same, and no longer say that all logging goes to
syslog: a server started with --foreground logs to stderr.

getting-started.md and the security model told extenddb manage users to
put the password in EXTENDDB_ADMIN_PASSWORD. extenddb init reads that
variable for the first admin's password. extenddb manage reads
EXTENDDB_PASSWORD when --password is not given. The notes now set it
with read -rs, which keeps it out of shell history. They also say that
the other password flags and --secret-access-key have no environment
variable.

Signed-off-by: Lee Hannigan <29015211+LeeroyHannigan@users.noreply.github.com>
@LeeroyHannigan LeeroyHannigan added v1 Needed for the 1.0 release documentation Improvements or additions to documentation labels Nov 5, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation v1 Needed for the 1.0 release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant