tegwick
24c1f56f00
Assistant: codex Assistant-Model: gpt-6.1-sol Assistant-Session: 01a126e1-76f8-7643-8cf3-e93336539ade
97 lines
6.2 KiB
Markdown
97 lines
6.2 KiB
Markdown
# Proposed Secrets exact execution policy and initiating-provider boundary
|
|
|
|
Prepared for Secrets SECRETS-WP-0013-T01 and Platform RPF-WP-0035-T12.
|
|
This is a proposed Access source contract. It adopts no new identity protocol,
|
|
issuer/client/key, runtime provider, source standard or native entitlement.
|
|
|
|
## Why the separate policy exists
|
|
|
|
Lifecycle v2 deliberately serves twelve generic operations. Existing apply
|
|
ignores execution_contract and its service subject cannot prove which human
|
|
initiated a task. The new package secrets-engine.task-execution v1 recognizes
|
|
only execute-ccr and is separate from secrets-engine.catalog-lane.lifecycle v2.
|
|
The entire execution descriptor, including operation/CCR/grant/catalogue/source,
|
|
ordered two-object read/write/readback plan, budget and deadline, participates in
|
|
existing canonical request and approval-free digest joins. No translation to
|
|
apply and no service administrative grant occurs.
|
|
|
|
The shipped source package is deliberately closed: owner_admission is a literal
|
|
false. An unsigned verified, owner_admission or human_control request flag cannot
|
|
open it. Synthetic future-provider tests replace that literal in an isolated
|
|
in-memory package only; those allows are not runtime admission or native evidence.
|
|
This is an enforced refusal until the identity boundary exists, not a switch to
|
|
turn on once a human approves a proposal.
|
|
|
|
## Reuse the actual providers
|
|
|
|
* KeyCape owns authentication/MFA and RS256 access-token issuance. Reuse
|
|
docs/approval-engine-auth-contract.md and docs/tenant-claim-contract.md from
|
|
KeyCape: exact issuer/audience/subject/principal_type/tenant/tenant_source,
|
|
expiry and assurance level/mfa/source/at. internal/taskexecution's proposed
|
|
source verifier consumes the token out of band using locally owner-pinned RSA
|
|
keys, trusted server time and no JWT-selected discovery URL. It returns an
|
|
opaque Initiator, never a token or an authorization decision. No real issuer,
|
|
key or client is installed in the source. Human initiating audience/client
|
|
admission is still missing; an approval-engine access audience cannot silently
|
|
be reused for task execution.
|
|
* Access's existing callerauth TokenReview choke point authenticates the service
|
|
transport and binds secrets-engine to its exact Kubernetes principal. It does
|
|
not authenticate the request's subject human or prove representation. Reuse
|
|
that authenticated server identity, never caller transport_principal text.
|
|
* User Engine owns canonical user and active tenant account/membership facts;
|
|
Tenant Engine owns authoritative tenant existence/lifecycle. Their live,
|
|
authenticated, freshness-bounded read interfaces must be integrated by Access
|
|
(PIP consumption), with unavailable/stale facts reducing authority. No new
|
|
parallel identity engine or caller-authored membership provider is introduced.
|
|
* Approval Engine supplies the served approval claim and authenticated consumption
|
|
facts. Its human approver can differ from the initiating human: a successful
|
|
approval is not initiating identity. Existing claim/PDP canonical correspondence
|
|
and later independent consume confirmation remain mandatory.
|
|
|
|
KeyCape explicitly states registration-supplied tenant is store isolation, not
|
|
human membership. The source verifier therefore requires directory provenance,
|
|
exact tenant:platform, verified MFA within 300 seconds and a currently valid
|
|
RS256 token. This strict proposed ceiling currently refuses registration-only
|
|
humans; changing that requirement requires owner-reviewed doctrine, not relabeling
|
|
registration as directory. Cryptographic verification alone still grants nothing:
|
|
User/Tenant membership, representation and exact operation are separate facts.
|
|
|
|
## Required server injection and activation proof
|
|
|
|
The task_execution_projection shape in the candidate policy is a proposed
|
|
internal server representation, not an accepted public claim format. Access
|
|
must acquire initiator token on a separate authenticated channel, verify it,
|
|
resolve canonical user/membership/tenant using the owning PIPs, correlate it with
|
|
the authenticated transport and full exact operation, and inject a bounded
|
|
projection. Raw human JWTs must never enter CheckRequest context or decision/audit
|
|
records. An HTTP-supplied projection must be rejected or discarded before any
|
|
trusted projection is injected, including nested/duplicate-field collisions.
|
|
|
|
Projection expiry must be the earliest identity/session expiry, provider
|
|
freshness deadline, approved operation deadline and PDP authority ceiling.
|
|
Fresh PIP retrieval/refusal and revocation visibility must be recorded; cached
|
|
membership alone cannot silently extend a KeyCape session. Package activation
|
|
requires an actual authenticated KeyCape origin/client, admitted User/Tenant read
|
|
routes/identities, server-controlled provenance and exact request/claim binding.
|
|
No raw JWT verifier endpoint, projection injection, transport-to-human binding,
|
|
PIP resolver, new server route or native package deployment is implemented here.
|
|
Only a reviewed versioned source successor may remove the hard refusal after
|
|
these gates have executable counterexamples. There is no unsigned enable flag.
|
|
|
|
## Tested scope and unfinished integration
|
|
|
|
Source tests verify RSA signatures and wrong issuer/audience/principal/tenant,
|
|
registration provenance, missing/stale MFA, expired/future token and absent key
|
|
admission. Strict nested duplicate/trailing JSON is refused. Python uses the
|
|
actual Secrets ExecutionContract parser and canonical request/approval digest
|
|
functions; Go and OPA evaluate the same complete synthetic two-object descriptor.
|
|
Synthetic future-projection allow and mutation denials prove candidate semantics;
|
|
current package denies regardless of asserted flags. They do not prove providers.
|
|
|
|
The candidate predicate is not a full independent typed owner compiler: source
|
|
and body provenance, exact estate origin/CCR readiness, bounded parser admission,
|
|
platform plan compilation and immutable body mediation remain Platform/Secrets
|
|
requirements. Nor does it independently validate served approval claims, consume,
|
|
run journal admission, dispatch or issue/revoke native grants. Existing journal,
|
|
confirmation and descriptor work must be integrated before this can perform one
|
|
metadata action. No existing operational task closes from this source package.
|