Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

feat(audit): audit credential-disclosure reads (provider environment, inference bundle)

Ouverte
  • Quelque chose ne va pas ?
#3,017 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
45/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
grpc, rust
Domaine
api, security

Piste de recherche

Commencez par GetSandboxProviderEnvironment et GetInferenceBundle dans crates/openshell-server/src/grpc/, puis lisez l’helper d’audit, le mapping principal-to-actor et le master toggle de #2911 et #2912. Définissez la couverture des tentatives réussies et échouées, des champs principal/ressource/corrélation et des tests de redaction de secret-canary ; le travail est terminé lorsque les deux RPCs émettent des événements documentés et contrôlés par toggle, sans contenu d’identifiants, et que le guide destiné aux contributors couvre les futures lectures de disclosure.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

state:accepted topic:observability

User Story

As a security or compliance owner running OpenShell, I want the gateway RPCs that hand out secret-bearing material — a sandbox's provider environment, an inference bundle — to emit a structured audit event recording who requested the disclosure and when, so that credential access is as accountable as credential change, even though the read alters no state.

Problem Statement

OpenShell is gaining a structured audit trail for state-changing gateway operations (#2911) and for authentication and authorization outcomes (#2912). Neither covers credential-disclosure reads: RPCs that return secret-bearing material to a caller without changing any state. GetSandboxProviderEnvironment returns a sandbox's resolved provider credentials, and GetInferenceBundle returns inference credential material. Today these produce no audit record. A read is not a mutation, so it sits outside #2911's mutations-only scope; a successful, authorized read is not an auth failure, so it sits outside #2912. The disclosure is therefore invisible in the audit trail.

Impact / Why This Matters

After a suspected credential leak, or during a routine access review, an operator needs to answer "who pulled this sandbox's provider credentials, and when?" and "which principal fetched the inference bundle?" Those questions have no data behind them today. Mutation is accounted for and authentication is accounted for, but the moment secret material actually leaves the gateway to a caller is not. The current workaround — correlating diagnostic logs with request traces — is not a stable audit contract and may not reliably identify the principal or the resource. The audit record must name the principal and the resource disclosed, and must never contain the disclosed secret itself.

Proposed Design

Each gateway RPC that returns secret-bearing material emits one structured OCSF audit event per attempt — on success and on failure — naming the authenticated principal (taken from the session, not the request), the resource disclosed (provider or profile id, sandbox id, inference route), the outcome, and a correlation id. The event never carries credential values, tokens, or bundle contents. It reuses the same audit helper, actor model, and master toggle that govern the control-plane audit events, so disclosure-read auditing turns on and off with the rest of the trail. The OCSF class is left to the implementer — an Entity Management (3004) access/read activity or a dedicated access event both fit. Because disclosure reads can be higher-volume than mutations, a finer toggle to gate their capture is a reasonable option, but the master audit toggle governs by default.

Acceptance Criteria

  • Each gateway RPC that discloses secret-bearing material (GetSandboxProviderEnvironment, GetInferenceBundle, and any peer added later) emits one audit record per attempt, on both success and failure.
  • The record names the authenticated principal, the disclosed resource (stable identifier), the outcome, and a correlation id.
  • No credential value, token, or bundle content appears in any record; automated tests cover representative secret canaries.
  • Emission is governed by the existing [openshell.gateway.audit] master toggle.
  • Contributor documentation notes that a new secret-disclosing read RPC must emit a disclosure-audit event.
  • The event, its fields, and redaction behavior are documented for operators.

Alternatives Considered

  • Fold into #2911. Rejected: reads are not mutations. Adding them to the mutation catalog blurs "what changed" with "what was accessed" and gives the two very different volume and retention characteristics one owner.
  • Rely on network or proxy telemetry. A proxy can see a request but not the authenticated principal established at the gateway boundary, nor the store outcome, so it cannot attribute the disclosure.
  • Accept the gap. Leaves credential access unaccountable, which is precisely the case an operator most needs to reconstruct.

Agent Investigation

  • The disclosing RPCs are GetSandboxProviderEnvironment and GetInferenceBundle in the gateway (crates/openshell-server/src/grpc/), with the authenticated principal already available at the boundary.
  • The audit helper, principal→actor mapping, and master toggle being contributed for #2911/#2912 are directly reusable here — this is incremental instrumentation, not new infrastructure.
  • This scope was explicitly deferred in the original audit-taxonomy design (recorded as out of the mutation scope). It has no home in the current decomposition, which is why it is filed as its own request.

Checklist

  • I've reviewed existing issues and the architecture docs
  • This is a design proposal, not a "please build this" request
Langage dominant
Rust
Étoiles
15.4k
Forks
1.7k
Merge moyen
2 j 22 min
PR mergées (30 j)
352

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de NVIDIA/OpenShell

Toutes les issues de NVIDIA/OpenShell

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.