Open-source .NET secret-management libraries for Infisical and Azure Key Vault.
One small common read contract, typed provider-native operations, and explicit application-owned authority.
🚧 Active Pre-Release Development: SecretKit is an unpublished development preview. Local packages and selected provider checks exist; they do not establish complete API coverage, production readiness, or a public NuGet release. Start with the current preview.
Documentation · Current Preview · Quickstart · Developer Guide · Sponsor
SecretKit is an in-process .NET 10 SDK for applications that explicitly select Infisical or Azure Key Vault. Common reads and metadata inventory stay small; provider-specific writes, authentication, lifecycle, and administration retain their native semantics.
The consuming application owns credential injection, permissions, configuration meaning, client activation, and persistence. Installing a package does not grant provider access. SecretKit has no dependency on Event or Configurator applications.
The current priority is the two-provider SDK. Broader administration and guided Configurator deployment are separate outcomes; see scope and future orchestration.
- 🔑 Explicit Provider Selection: Read through a selected client and authority-bound reference, without an implicit fallback identity.
- 🧩 Small Common Contracts: Use
ISecretReaderandISecretInventorywhile preserving provider-owned coordinates and version semantics. - 🔒 Owned Secret Material: Dispose successful reads after use; deliberate string export remains a separate plaintext boundary.
- 📦 Optional Composition: Add configuration snapshots or hosting integration only when the application needs them.
- 🛡️ Separate Identities: Assess access through the intended runtime identity rather than treating administrator visibility as delivery.
- 📜 Typed Native Operations: Use supported provider-specific operations without a raw-request escape hatch or invented cross-provider guarantees.
- 🔍 Bounded Evidence: Distinguish absence, denial, unknown outcomes, incomplete inventories, and unverified compatibility.
- 🧪 Offline Examples: Explore required bootstrap, generation replacement, and fresh access assessment without a provider account.
- 🆓 MIT-Licensed SDK: First-party libraries use MIT; dependencies retain their own licenses and notices.
- 🏗️ Independent Libraries: Core uses the BCL only. No database, UI, or ASP.NET shared framework is required.
- 📚 Two Documentation Tracks: Public guides explain adoption; internal specifications record design and verification boundaries.
- 🧭 Host-Owned Policy: Keep tenant isolation, readiness, reload scheduling, and fleet convergence in the application that owns them.
SecretKit runs inside your application. Choose the packages that match its responsibilities:
| Package | Responsibility | Package Guide |
|---|---|---|
SecretKit.Core |
Common reads, metadata inventory, outcomes, references, and disposable material | Core Contracts |
SecretKit.Infisical |
Infisical runtime access and supported native lifecycle/authentication operations | Infisical |
SecretKit.AzureKeyVault |
Azure Key Vault secret data-plane access | Azure Key Vault |
SecretKit.Infisical.Management |
Optional, explicitly authorized Infisical administration | Infisical Administration |
SecretKit.AzureKeyVault.Management |
Optional Azure administration and separately authorized audit access | Azure Administration |
SecretKit.Extensions.Configuration |
Prepared generations and deliberate plaintext configuration export | Configuration |
SecretKit.Extensions.Hosting |
Explicitly started authentication maintenance and health integration | Hosting |
These packages are present in the checkout, with bounded implemented subsets. Package existence is not complete native-operation support. Local installation evidence, offline tests, and live provider conformance have different scopes; consult the current preview before selecting an operation.
Your application selects its provider, origin, credentials, and key mapping. Optional snapshots publish a complete local generation; they do not promise a remote transaction or activate your application clients for you.
Configurator may eventually orchestrate setup using these building blocks. No working end-to-end deployment workflow is claimed. See configuration and runtime and scope and orchestration.
- Selected Authority: References belong to a specific client; credentials and remote provider policy remain the authority for access.
- Material Ownership: Successful reads own disposable material.
Revealand configuration export create ordinary managed strings that SDK disposal cannot erase. - Controlled Networking: SDK-owned transports bound responses and use documented origin, redirect, retry, and diagnostic controls. Host-supplied instrumentation remains the host's responsibility.
- Mutation Uncertainty: Supported mutations retain caller-held receipts. A lost response can leave an unknown outcome; the SDK does not silently replay the write.
- Honest Support Claims: Offline tests cannot prove provider permissions, editions, cloud compatibility, or destination delivery.
See SECURITY.md, runtime contracts, and the current preview for exact boundaries. No security certification or compliance accreditation is claimed.
This checkout is an unpublished preview. You can build local packages and evaluate supported slices, but no public package availability or production support policy is established. Azure live verification, broader provider coverage, and publication gates remain explicit limits in the current preview.
SecretKit is a client library. Infisical or Azure Key Vault stores and governs the secrets. Your application supplies credentials and chooses the identity; SecretKit does not provision a provider or discover an administrative principal automatically.
Dispose each successful SecretRead to release its owned material. Strings created by Reveal, exported configuration values, logs, and downstream library copies are outside that buffer's lifetime. Review the application's plaintext boundaries and instrumentation.
Metadata inventory and value access are separate operations. An administrator seeing a secret does not prove runtime access, freshness, downstream delivery, or application activation. The ProviderAssessment sample demonstrates that distinction with controlled offline identities.
Supported writes retain provider-native semantics and uncertainty. A complete local configuration generation avoids publishing a partial mixture, but it is not a multi-key remote snapshot, transaction, or rollback. Applications own validation and activation.
Ordinary Infisical or direct Azure Key Vault access does not require a connection to a deployment destination. The broad Infisical third-party connection/sync catalog has been removed from local source; selected optional administration and native secret features remain. Local post-removal verification passed. See the accepted scope decision.
The repository scope describes the current two-provider priority and future orchestration. The wider ISLAMU roadmap provides ecosystem context. Propose SecretKit changes through issues; a roadmap entry is not an implemented support claim.
You can help by reporting reproducible bugs, improving adopter guides, testing supported provider combinations with owned identities, or contributing focused SDK changes. Read CONTRIBUTING.md before opening a pull request and follow the Code of Conduct.
Install .NET SDK 10.0.302, as pinned in global.json, then use an independent checkout:
git clone https://github.com/islamu-ngo/SecretKit.git
cd SecretKit
dotnet restore SecretKit.slnx --locked-mode
dotnet build SecretKit.slnx --configuration Release --no-restore
dotnet run --project samples/RuntimeConfiguration --configuration Release --no-build
dotnet run --project samples/ProviderAssessment --configuration Release --no-buildBoth samples run offline demonstrations, without real provider credentials, database connections, or remote mutations. They illustrate SDK ownership and consumer policy; they do not establish live provider conformance.
For verification and local packages:
dotnet test --solution SecretKit.slnx --configuration Release --no-build
dotnet format SecretKit.slnx --verify-no-changes --verbosity quiet
dotnet pack SecretKit.slnx --configuration Release --no-build --output artifacts/packagesPacking creates local evaluation artifacts and does not publish them. The project guide maps owners and focused commands; the agent contract records invariants and verification expectations.
- Read CONTRIBUTING.md and run the offline quickstart.
- Use PROJECTS.md to locate the package and tests for your change.
- Check the current preview, architecture, and runtime contracts.
- For AI-assisted work, follow AGENTS.md and review every proposed change.
Contribute material you have the right to license under the repository's MIT license. Preserve provenance and dependency notices. SecretKit has its own contribution contract; Event's AGPL and CLA workflows do not apply automatically. Vendor or sibling-project implementation source must not be copied into these libraries.
The documentation hub routes readers to the correct track. Design documents explain intent; the current-preview page identifies implemented behavior and remaining verification gates.
| Guide | Reader Question |
|---|---|
| Current Preview | What is implemented and what remains unverified? |
| Adoption and Value | Where might this SDK help my application? |
| Configuration and Runtime | Who owns secrets, generations, and activation? |
| Operations and Compatibility | How are native support and compatibility bounded? |
| Scope and Orchestration | How do core access, administration, and deployment differ? |
| Engineering Concern | Repository Document |
|---|---|
| Project ownership and local commands | PROJECTS.md |
| Contributor and agent invariants | AGENTS.md |
| Package boundaries | SDK_ARCHITECTURE.md |
| Ownership, cancellation, outcomes, and receipts | RUNTIME_CONTRACTS.md |
| Admission, maintenance, and publication gates | DELIVERY_AND_MAINTENANCE.md |
| Engineering evidence and provider registries | Internal Documentation |
| Layer | Technology |
|---|---|
| Runtime | .NET 10 / C# 14; SDK pinned in global.json |
| Core | BCL-only contracts |
| Infisical transport | Handwritten typed contracts, Refit, and controlled HttpClient transport |
| Azure access | Official Azure SDK with explicit credentials |
| Optional composition | Microsoft.Extensions.Configuration and hosting abstractions |
| Tests | TUnit / Microsoft.Testing.Platform |
| Dependency management | Central versions and generated package lockfiles |
Meet the wider ISLAMU community on Discord. Use SecretKit issues for reproducible SDK bugs and proposals. All participation follows the Code of Conduct.
Report vulnerabilities privately to contact@openislamu.org, including security fixes discovered in forks. Keep credentials, secret values, and confidential provider coordinates out of reports and public pull requests. Read SECURITY.md for disclosure guidance.
| Amir Akrari |
|---|
 |
| GitHub · Bluesky |
Thank you to everyone who contributes code, documentation, testing, and review.
Support the ISLAMU open-source work behind SecretKit:
- Monthly support via Stripe
- One-time contribution
- For organizational support, contact contact@openislamu.org.
Provider test environments, infrastructure, and review time can help establish verified support. Discuss an offer privately with the maintainers before sharing credentials or granting access.
- ISLAMU Event: event platform and management system.
- ISLAMU Configurator: offline configuration preparation utility.
- I-VSD: Islamic Value Sensitive Design framework.
SecretKit builds on .NET, Refit, the Azure SDK, Microsoft.Extensions, and TUnit. Infisical and Azure Key Vault provide the native services these adapters address. Exact direct versions live in Directory.Packages.props; attribution and distribution boundaries live in THIRD-PARTY-NOTICES.md.
SecretKit is part of the ISLAMU open-source ecosystem. Sponsorship, contributions, and practical verification help maintain the SDK and its provider contracts. Contact the maintainers to discuss support or integration needs.
For ordinary SDK questions and problems, open a repository issue or join Discord. For private matters, email contact@openislamu.org.
SecretKit's first-party libraries are licensed under MIT. Third-party dependencies keep their own terms. Event is a separately governed application; its licensing does not change SecretKit's license or create a runtime dependency.
Core remains independent of provider SDKs and host frameworks. Provider adapters depend inward on Core; configuration export, hosting, and management remain optional packages. Publication requires its own provenance, verification, publisher rights, and authorization; a local package build does not satisfy those gates.