用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/rudironsoni/Synaxis --skill dotnet-secrets-management命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
Routes .NET/C# work to domain skills. Loads coding-standards for code paths.
基于 SOC 职业分类
| name | dotnet-secrets-management |
| category | security |
| subcategory | secrets |
| description | Manages secrets and sensitive config. User secrets, environment variables, rotation. |
| license | MIT |
| targets | ["*"] |
| tags | ["security","dotnet","skill"] |
| version | 0.0.1 |
| author | dotnet-agent-harness |
| invocable | true |
| claudecode | {"allowed-tools":["Read","Grep","Glob","Bash","Write","Edit"]} |
| codexcli | {"short-description":".NET skill guidance for security tasks"} |
| opencode | {"allowed-tools":["Read","Grep","Glob","Bash","Write","Edit"]} |
| copilot | {} |
| geminicli | {} |
| antigravity | {} |
Cloud-agnostic secrets management for .NET applications. Covers the full lifecycle: user secrets for local development, environment variables for production, IConfiguration binding patterns, secret rotation, and managed identity as a production best practice. Includes anti-patterns to avoid (secrets in source, appsettings.json, hardcoded connection strings).
Cross-references: [skill:dotnet-security-owasp] for OWASP A02 (Cryptographic Failures) and deprecated pattern warnings, [skill:dotnet-csharp-configuration] for Options pattern and configuration source precedence.
| Environment | Secret Source | Mechanism |
|---|---|---|
| Local dev | User secrets | dotnet user-secrets CLI, secrets.json outside repo |
| CI/CD | Pipeline variables | Injected as environment variables, never in YAML |
| Staging/Production | Environment variables or vault | OS-level env vars, managed identity, or vault provider |
Principle: Secrets must never exist in the source repository or in any file committed to version control. Each environment tier uses the appropriate mechanism for its trust boundary.
User secrets store sensitive configuration outside the project directory in the user profile, preventing accidental commits.
# Do NOT commit real secrets; use dotnet user-secrets or env vars
# Initialize user secrets for a project (creates UserSecretsId in csproj)
dotnet user-secrets init
dotnet user-secrets
dotnet user-secrets
dotnet user-secrets
dotnet user-secrets list
dotnet user-secrets remove
dotnet user-secrets clear
User secrets are stored at:
%APPDATA%\Microsoft\UserSecrets\<UserSecretsId>\secrets.json~/.microsoft/usersecrets/<UserSecretsId>/secrets.jsonThe secrets.json file is plain JSON with the same structure as appsettings.json:
{
"ConnectionStrings": {
"DefaultDb": "Server=localhost;Database=myapp;User=sa;Password=<DB_PASSWORD_PLACEHOLDER>"
},
"Smtp": {
"ApiKey": "<SENDGRID_API_KEY_PLACEHOLDER>"
},
"Jwt": {
"SigningKey": "<JWT_SIGNING_KEY_PLACEHOLDER>"
}
}
User secrets are loaded automatically by WebApplication.CreateBuilder and Host.CreateDefaultBuilder when
DOTNET_ENVIRONMENT or ASPNETCORE_ENVIRONMENT is Development:
var builder = WebApplication.CreateBuilder(args);
// User secrets are already loaded. Access them via IConfiguration:
var connectionString = builder.Configuration.GetConnectionString("DefaultDb");
For non-web hosts (console apps, worker services):
var builder = Host.CreateApplicationBuilder(args);
// User secrets are loaded automatically in Development environment.
// For explicit control:
if (builder.Environment.IsDevelopment())
{
builder.Configuration.AddUserSecrets<Program>();
}
Gotcha: User secrets are not encrypted -- they are just stored outside the repo. They are appropriate for development only, never for production.
Environment variables are the standard mechanism for injecting secrets into production applications without touching the filesystem.
In the default ASP.NET Core configuration stack, environment variables override file-based sources (last wins):
appsettings.jsonappsettings.{Environment}.json.NET maps environment variables to configuration keys using __ (double underscore) as the section separator:
# These environment variables map to configuration sections:
export ConnectionStrings__DefaultDb="Server=prod-db;Database=myapp;..."
export Smtp__ApiKey="<SENDGRID_API_KEY_PLACEHOLDER>"
export Jwt__SigningKey="<JWT_SIGNING_KEY_PLACEHOLDER>"
# With a prefix (recommended to avoid collisions):
export MYAPP_ConnectionStrings__DefaultDb="Server=prod-db;..."
// Load prefixed environment variables
builder.Configuration.AddEnvironmentVariables(prefix: "MYAPP_");
// Access the same way as any configuration source:
var smtpKey = builder.Configuration["Smtp:ApiKey"];
# docker-compose.yml -- inject secrets via environment
services:
api:
image: myapp:latest
environment:
- ConnectionStrings__DefaultDb=Server=db;Database=myapp;User=sa;Password=<DB_PASSWORD_PLACEHOLDER>
- Smtp__ApiKey=${SMTP_API_KEY}
env_file:
- .env # NOT committed to source control
# Dockerfile -- do NOT bake secrets into images
# Use environment variables at runtime instead
ENV ASPNETCORE_URLS=http://+:8080
# NEVER: ENV ConnectionStrings__DefaultDb="Server=..."
Gotcha: Environment variables are visible to all processes under the same user. In multi-tenant container environments, use container-level isolation (Kubernetes secrets, Docker secrets) rather than host-level env vars.
Bind secrets to strongly typed options classes for compile-time safety and validation.
public sealed class JwtOptions
{
public const string SectionName = "Jwt";
[Required, MinLength(32)]
public string SigningKey { get; set; } = "";
/// <summary>
/// Previous signing key retained during rotation window.
/// Set this when rotating keys so tokens signed with the old key
/// remain valid until they expire. Remove after rotation completes.
/// </summary>
public string? PreviousSigningKey { get; set; }
[Required]
public string Issuer { get; set; } = "";
[Required]
public string Audience { get; set; } = "";
[Range(1, 1440)]
public int ExpirationMinutes { get; set; } = 60;
}
// Registration with validation
builder.Services
.AddOptions<JwtOptions>()
.BindConfiguration(JwtOptions.SectionName)
.ValidateDataAnnotations()
.ValidateOnStart(); // Fail fast if secrets are missing
// Inject and use
public sealed class TokenService(IOptions<JwtOptions> jwtOptions)
{
private readonly JwtOptions _jwt = jwtOptions.Value;
public string GenerateToken(string userId)
{
var key = new SymmetricSecurityKey(
Encoding.UTF8.GetBytes(_jwt.SigningKey));
var credentials = new SigningCredentials(key, SecurityAlgorithms.HmacSha256);
var token = new JwtSecurityToken(
issuer: _jwt.Issuer,
audience: _jwt.Audience,
claims: [new Claim(ClaimTypes.NameIdentifier, userId)],
expires: DateTime.UtcNow.AddMinutes(_jwt.ExpirationMinutes),
signingCredentials: credentials);
return new JwtSecurityTokenHandler().WriteToken(token);
}
}
Options classes must use
{ get; set; }(not{ get; init; }) because the configuration binder andPostConfigureneed to mutate properties after construction. Use data annotation attributes ([Required],[MinLength]) for validation.
Gotcha: ValidateOnStart() catches missing secrets at application startup rather than at first use. Always use it
for secrets-bearing options to fail fast with a clear error message.
Design applications to handle secret rotation without downtime.
// Use IOptionsMonitor<T> for secrets that may change at runtime
public sealed class EmailService(IOptionsMonitor<SmtpOptions> smtpOptions, ILogger<EmailService> logger)
{
public async Task SendAsync(string to, string subject, string body)
{
// CurrentValue reads the latest configuration on every call
var options = smtpOptions.CurrentValue;
logger.LogDebug("Using SMTP host {Host}", options.Host);
// ... send email using current options ...
}
}
// Audit-log configuration changes via a hosted service.
// IHostedService is always activated by the host, so the subscription is guaranteed.
public sealed class SmtpOptionsChangeLogger(
IOptionsMonitor<SmtpOptions> monitor,
ILogger<SmtpOptionsChangeLogger> logger) : IHostedService, IDisposable
{
private IDisposable? _subscription;
public Task StartAsync(CancellationToken cancellationToken)
{
_subscription = monitor.OnChange(options =>
{
logger.LogInformation("SMTP configuration reloaded at {Time}", DateTime.UtcNow);
});
return Task.CompletedTask;
}
public Task StopAsync(CancellationToken cancellationToken) => Task.CompletedTask;
public void Dispose() => _subscription?.Dispose();
}
// Registration:
builder.Services.AddHostedService<SmtpOptionsChangeLogger>();
// Dual-key validation for zero-downtime rotation
// Accept both old and new signing keys during rotation window
public sealed class DualKeyTokenValidator(IOptionsMonitor<JwtOptions> optionsMonitor)
{
public TokenValidationParameters GetParameters()
{
// Read CurrentValue on every call so rotated keys are picked up
// without restarting the application
var options = optionsMonitor.CurrentValue;
var keys = new List<SecurityKey>
{
new SymmetricSecurityKey(Encoding.UTF8.GetBytes(options.SigningKey))
};
if (!string.IsNullOrEmpty(options.PreviousSigningKey))
{
keys.Add(new SymmetricSecurityKey(
Encoding.UTF8.GetBytes(options.PreviousSigningKey)));
}
return new TokenValidationParameters
{
ValidateIssuer = true,
ValidIssuer = options.Issuer,
ValidateAudience = true,
ValidAudience = options.Audience,
ValidateLifetime = true,
IssuerSigningKeys = keys
};
}
}
Managed identity eliminates secrets entirely for cloud-hosted applications by using the platform's identity system to authenticate to services.
Concept: Instead of storing a connection string with a password, the application authenticates to the database/service using its platform-assigned identity. No secret to manage, rotate, or leak.
// Example: passwordless connection to SQL Server using DefaultAzureCredential
// This pattern works across Azure, and similar patterns exist for AWS and GCP
var connectionString = "Server=myserver.database.windows.net;Database=mydb;Authentication=Active Directory Default";
builder.Services.AddDbContext<AppDbContext>(options =>
options.UseSqlServer(connectionString));
// No password in the connection string -- identity is resolved from the environment
When to use managed identity:
When you still need secrets:
// NEVER: hardcoded secrets in source code
// Replaced real keys with placeholders. Do NOT store real keys in source.
private const string ApiKey = "<API_KEY_PLACEHOLDER>"; // WRONG: hardcoded secret
private const string ConnectionString = "Server=prod-db;Database=myapp;User=sa;Password=<DB_PASSWORD_PLACEHOLDER>"; // WRONG: hardcoded secret
Fix: Use user secrets (dev) or environment variables (production). See sections above.
{
"ConnectionStrings": {
"DefaultDb": "Server=prod-db;Password=<DB_PASSWORD_PLACEHOLDER>"
}
}
Fix: appsettings.json should contain only non-sensitive defaults. Use placeholder values that fail visibly:
{
"ConnectionStrings": {
"DefaultDb": "Server=localhost;Database=myapp;Integrated Security=true"
},
"Smtp": {
"ApiKey": "REPLACE_VIA_ENV_OR_USER_SECRETS"
}
}
// NEVER: connection strings directly in code
// Use IConfiguration or environment variables instead of hardcoded credentials.
var connection = new SqlConnection("Server=prod-db;Database=myapp;User=sa;Password=<DB_PASSWORD_PLACEHOLDER>"); // WRONG
Fix: Always resolve connection strings from IConfiguration:
// Correct: resolve from configuration
public sealed class OrderRepository(IConfiguration configuration)
{
private readonly string _connectionString =
configuration.GetConnectionString("DefaultDb")
?? throw new InvalidOperationException("ConnectionStrings:DefaultDb is not configured");
}
// Better: use Options pattern with validation
public sealed class OrderRepository(IOptions<DatabaseOptions> options)
{
private readonly string _connectionString = options.Value.ConnectionString;
}
// NEVER: log secret values
logger.LogInformation("Using API key: {ApiKey}", apiKey); // WRONG
logger.LogDebug("Connection string: {Conn}", connectionString); // WRONG
Fix: Log that a secret was loaded, not its value:
logger.LogInformation("API key configured: {IsConfigured}", !string.IsNullOrEmpty(apiKey));
logger.LogInformation("Database connection configured for {Server}", new SqlConnectionStringBuilder(connectionString).DataSource);
IConfiguration or IOptions<T> to resolve secrets.
Even in examples, use placeholder values.appsettings.json -- it is committed to source control. Use user secrets for
development, environment variables for production.{ get; init; } on Options classes -- the configuration binder requires mutable setters. Use
{ get; set; } with data annotation validation instead.ValidateOnStart() -- without it, missing secrets cause runtime failures at first use rather than a
clear startup error.IsConfigured: true/false) or metadata (server
name from connection string), never the value.IOptions<T> for secrets that rotate -- use IOptionsMonitor<T> for runtime-reloadable secrets so
rotation does not require a restart.Microsoft.Extensions.Configuration.UserSecrets (included in ASP.NET Core SDK; add manually for console apps)Microsoft.Extensions.Options.DataAnnotations for ValidateDataAnnotations()Primary approach: Use Serena symbol operations for efficient code navigation:
serena_find_symbol instead of text searchserena_get_symbols_overview for file organizationserena_find_referencing_symbols for impact analysisserena_replace_symbol_body for clean modificationsWhen to use Serena vs traditional tools:
Example workflow:
# Instead of:
Read: src/Services/OrderService.cs
Grep: "public void ProcessOrder"
# Use:
serena_find_symbol: "OrderService/ProcessOrder"
serena_get_symbols_overview: "src/Services/OrderService.cs"