Access Employees

Infisical Secrets Management with .NET

Published in by Gustavo Mauricio de Barros

Infisical Secrets Management with .NET Infisical Secrets Management with .NET

Introduction

Infisical is a secrets management platform that centralizes credentials, tokens, and other sensitive variables in a secure location. Instead of spreading secrets across files, local environment variables, and CI/CD pipelines, you keep everything organized by project, environment, and path, with proper access control and audit logging.

Benefits of Infisical

  • Centralization of secrets in a single trusted location
  • Environment separation (dev, staging, prod) without duplicating configuration
  • Access control by team, project, and secret path
  • Audit logs for secret access and changes
  • Simple integration with applications and pipelines

.NET Integration: JJConsulting.Infisical

To use Infisical in an idiomatic way within .NET applications, we created JJConsulting.Infisical.

The library connects Infisical to the .NET configuration system and registers DI services for direct secret access when needed.

It:

  • Adds an Infisical configuration provider to IConfiguration
  • Registers IInfisicalAuthenticationService and IInfisicalSecretsService
  • Supports authentication via service token and machine identity

Installation

dotnet add package JJConsulting.Infisical
<ItemGroup>
  <PackageReference Include="JJConsulting.Infisical" Version="1.0.0" />
</ItemGroup>

Configuration with Service Token

Use a service token when you want a simple, environment-scoped authentication flow. Add the configuration to your appsettings.json and register it during startup:

{
  "Infisical": {
    "Environment": "prod",
    "ProjectId": "your-project-id",
    "ServiceToken": "your-service-token",
    "SecretPath": "/",
    "Url": "https://app.infisical.com"
  }
}
using JJConsulting.Infisical.Configuration;

var infisicalConfig = ServiceTokenInfisicalConfig
    .FromConfiguration(builder.Configuration.GetSection("Infisical"));

builder.Host.AddInfisical(infisicalConfig);

Configuration with Machine Identity

If you prefer using client credentials, configure machine identity instead. The rest of the flow remains the same.

{
  "Infisical": {
    "Environment": "prod",
    "ProjectId": "your-project-id",
    "ClientId": "your-client-id",
    "ClientSecret": "your-client-secret",
    "SecretPath": "/",
    "Url": "https://app.infisical.com"
  }
}
using JJConsulting.Infisical.Configuration;

var infisicalConfig = MachineIdentityInfisicalConfig
    .FromConfiguration(builder.Configuration.GetSection("Infisical"));

builder.Host.AddInfisical(infisicalConfig);

Secret Naming Convention in .NET

The provider follows the standard .NET configuration convention: use double underscore (__) in Infisical keys to map nested configuration keys.

  • MySettings__MyKey becomes MySettings:MyKey
  • ConnectionStrings__DefaultConnection becomes ConnectionStrings:DefaultConnection
  • Logging__LogLevel__Default becomes Logging:LogLevel:Default

Values are cached in memory and remain available until the next application restart. This means temporary Infisical server interruptions will not immediately impact your running application.

Direct Secret Access via DI

Sometimes you need to fetch secrets directly (or refresh them on demand). The package registers IInfisicalSecretsService, so you can inject it wherever needed:

using JJConsulting.Infisical.Services;

public class MyService(IInfisicalSecretsService secretsService)
{
    public async Task UseSecretsAsync()
    {
        var all = await secretsService.GetSecretsAsync();
        var single = await secretsService.GetSecretAsync("DATABASE_PASSWORD");
    }
}

Conclusion

JJConsulting.Infisical keeps the integration lightweight and transparent. Secrets are loaded into IConfiguration, so you continue using the same native configuration APIs you already use with appsettings.json and environment variables, while still having direct access available when necessary.

To explore the source code, suggest improvements, or contribute, visit the GitHub repository.

More articles from this author

Using Static Lambdas and JetBrains’ RequireStaticDelegate in C#

Published in

This article examines the use of static lambdas, a feature introduced in C# 9, which prevents unnecessary heap allocations by disallowing variable captures in lambdas. It also highlights how the JetBrains [RequireStaticDelegate] attribute can assist in enforcing this pattern within APIs.

READ MORE
← Return to start