Workload Secrets

Workload Secrets replaces static credentials with dynamic, short-lived secrets generated at runtime — scoped to the requesting workload and expired automatically.

How Dynamic Secrets Work

When a workload requests credentials, WNCYBER:

1. Verifies the workload’s identity (via agent token, IAM role, or Kubernetes service account)
2. Checks the applicable secret policy
3. Creates a new credential in the upstream system (database, cloud provider, etc.)
4. Returns the credential with a TTL
5. Revokes the credential automatically when the TTL expires

The upstream system never holds a static password — credentials exist only for the duration of the requesting workload’s session.

Configuring Secret Paths

Secret paths define which secrets are available and to which workloads.

1. Navigate to Secrets → Secret Paths → New Path
2. Define:
   • Path name — e.g., database/production/api-db
   • Backend — the upstream system (PostgreSQL, MySQL, AWS, etc.)
   • Allowed requestors — which workload identities may request this secret
   • TTL — how long issued credentials remain valid (default: 1 hour)
3. Test the path with Generate Test Secret

Database Credentials

Supported Databases

PostgreSQL, MySQL, MariaDB, Microsoft SQL Server, Oracle, MongoDB, Redis.

Setup

1. Create a service account in the target database with the minimum permissions required
2. Grant WNCYBER the ability to create and revoke credentials under that service account
3. Configure the secret path with the database connection details
4. Workloads request credentials via the WNCYBER API or SDK

Issued credentials are unique to each workload request. If a credential is compromised, only that single workload session is affected — not all consumers of the database.

CI/CD Integration

GitHub Actions

Add the WNCYBER action to your workflow:

- name: Get database credentials
  uses: wncyber/secrets-action@v1
  with:
    secret-path: database/production/api-db
  id: secrets

- name: Run migrations
  env:
    DB_USER: ${{ steps.secrets.outputs.username }}
    DB_PASS: ${{ steps.secrets.outputs.password }}
  run: npm run db:migrate

Credentials are injected as masked environment variables and are never written to logs or artifacts.

Other CI/CD Platforms

WNCYBER supports native integrations with GitLab CI, Jenkins, Azure DevOps, CircleCI, and Bitbucket Pipelines. See the provider-specific guides for configuration examples.

Kubernetes Integration

Secrets Store CSI Driver

WNCYBER supports the Kubernetes Secrets Store CSI Driver for mounting dynamic secrets as volumes:

1. Install the WNCYBER provider for the Secrets Store CSI Driver
2. Create a SecretProviderClass referencing your secret path
3. Mount the secret in your pod spec — credentials are injected at pod startup and rotated automatically

Native Vault Injection (Sidecar)

Alternatively, deploy the WNCYBER sidecar injector:

1. Add the annotation wncyber.io/inject: "true" to your pod spec
2. Specify secret paths in the wncyber.io/secrets annotation
3. The sidecar injects credentials as environment variables at startup

Encryption Key Management

WNCYBER provides centralised encryption key management with automatic rotation:

1. Navigate to Secrets → Encryption Keys → New Key
2. Define the key purpose, algorithm (AES-256, RSA-4096), and rotation schedule
3. Applications reference keys by name — WNCYBER handles the underlying key material

Key rotation is transparent to consuming applications: WNCYBER re-encrypts existing data with the new key during the rotation window.