feat: standardized audit logging schema and service

Open
#87 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
go
Domain
backend, security

Research direction

Start by comparing Frontier's core/audit/ implementation with the previous auth/audit package referenced in the issue, then review evolution PR #85. Resolve the OrgID, multiple targets, and Level design questions before defining the shared schema, Repository interface, and context helpers; done means the common package design is agreed and its scope is separated from project-specific storage and publishing.

Written by the indexing model from the issue text.

Description

Context

The previous auth/audit package was too simple — flat actor string, no target, no org scoping, no event publishing. Meanwhile frontier has a rich audit system with typed actors/targets, org scoping, webhook publishing, and event filtering.

Every raystack service that needs audit logging builds its own. A shared schema would enable consistent audit trails across services.

Proposed solution

Salt provides the common schema and context helpers. Projects provide storage and publishing.

Schema
type Actor struct {
    ID   string
    Type string
    Name string
}

type Target struct {
    ID   string
    Type string
    Name string
}

type Log struct {
    ID        string
    OrgID     string
    Source     string
    Action    string
    Actor     Actor
    Target    Target
    Metadata  map[string]string
    CreatedAt time.Time
}
Interfaces
type Repository interface {
    Create(ctx context.Context, log *Log) error
    List(ctx context.Context, filter Filter) ([]Log, error)
    GetByID(ctx context.Context, id string) (Log, error)
}
Context helpers
audit.SetActor(ctx, Actor{ID: "user-123", Type: "user", Name: "alice"})
audit.SetMetadata(ctx, map[string]string{"ip": "1.2.3.4"})
What projects provide themselves
  • Storage implementation (postgres, kafka, external service)
  • Event name constants (app.user.created, etc.)
  • Publishing/webhook integration
  • Target helpers specific to their domain
Design questions
  • Is OrgID universal enough for the schema? (Compass doesn't have orgs)
  • Should Target support multiple targets per event?
  • Should the schema include a Level (info/warn/critical)?
References
  • Frontier's audit: core/audit/ — rich implementation with Actor/Target structs, webhook publishing
  • Guardian's audit: used old salt/audit with simple string actor
  • Previous auth/audit package dropped in salt evolution PR #85
Dominant language
Go
Stars
14
Forks
8
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from raystack/salt

All issues in raystack/salt

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.