Skip to content

Aembit Secrets Operator now supports more credential types

Aembit Secrets Operator 1.32.322 is now available.

Secrets Operator now retrieves any credential type your Access Policy issues—not just HashiCorp Vault tokens. A new credentialType field on the AembitSecretRefreshSchedule resource selects which Credential Provider type Aembit uses, and the managed Kubernetes Secret mirrors the Aembit Edge API credentials response for that provider.

  • New credentialType field: Choose OAuthToken (the default), ApiKey, UsernamePassword, AwsStsFederation, or GoogleWorkloadIdentityFederation. Each type writes its own Secret data keys—for example, UsernamePassword produces username and password, and AwsStsFederation produces awsAccessKeyId, awsSecretAccessKey, and awsSessionToken. See Credential types and Secret data keys.
  • Backward compatible: Schedules that omit credentialType keep writing a single token key, so existing HashiCorp Vault and cert-manager configurations need no change.
  • Clearer mismatch errors: When credentialType doesn’t match the configured Credential Provider, the schedule reports Aembit Edge API returned a credentials response with no populated fields instead of writing a blank Secret.
  • AWS credential redaction: Secrets Operator redacts the AWS access key, secret access key, and session token values from its debug logs.

Aembit Secrets Operator now available

Aembit Secrets Operator 1.31.298 is now available.

Secrets Operator is a Kubernetes operator that authenticates to the Aembit platform and synchronizes credentials into Kubernetes Secrets. Applications consume managed secrets the same way they consume any other Kubernetes Secret.

Key capabilities in this release:

  • Kubernetes Service Account authentication: Authenticate using the operator’s in-cluster ServiceAccount token, validated against the cluster’s OIDC endpoint. No per-cluster signing key required. Verified on Amazon EKS and K3s. See Set up Secrets Operator for configuration.
  • OIDC symmetric key authentication: Alternatively, authenticate using OIDC tokens with symmetric key signing (HS256) for custom claims and non-Kubernetes identity scenarios.
  • Proactive credential renewal: Credentials refresh at 80% of their TTL, or sooner when you configure a shorter refreshInterval, ensuring applications always have a valid credential.
  • Multi-namespace install: You can now use the same Helm release name across multiple namespaces on the same cluster without resource name conflicts.