Using Externally Defined Secrets

Table of Contents

Defining Your Secrets

Need help?

Schedule a consultation with an Azul performance expert.

Secrets can be externally defined to allow you to manage Kubernetes secrets independent of the Optimizer Hub configuration.

Defining Your Secrets

You can define the following secrets by overriding the following default settings in your values-override.yaml file:

blobstorage.s3.accesskey
blobstorage.s3.secretkey
azure.connectionString
azure.sasToken

Default Settings

These are the default settings with descriptions to describe how they are used.

 secrets:
  blobStorage:
    s3:
      # name of existing Secret object to use. New Secret is created if name is empty
      existingSecret: ""

      # name of *key* for `accessKey` value in K8S Secret. It can be renamed to match names in existing Secret
      accessKeySecretKey: blob-storage-accesskey

      # default value for accesskey - used when new secret is created
      accesskey: <yourAccessKey>

      # name of *key* for `secretkey` value in K8S Secret. It can be renamed to match names in existing Secret
      secretAccessKeySecretKey: blob-storage-secretkey

      # default value for s3.secretkey - used when new secret is created
      secretkey: <yourSecretKey>

    azure:
      # name of existing Secret object to use. New Secret is created if name is empty
      existingSecret: ""

      # name of *key* for `connectionStringSecretKey` value in K8S Secret. It can be renamed to match names in existing Secret
      connectionStringSecretKey: azure-storage-connection-string
      # connectionString: "<connection-string>" . For authMethod: connection-string,
      # get connection-string on Azure Portal > Storage accounts > {storage_account_name} > Access keys

      # name of *key* for `sasTokenSecretKey` in K8S Secret. It can be renamed to match names in existing Secret
      sasTokenSecretKey: azure-storage-sas-token
      # sasToken: "<sas-token>"  # For authMethod: sas-token,
      # Get sas-token on Azure Portal > Storage accounts > {storage_account_name} > {blob_container} > Shared access tokens

How To Use

If you keep the default values, the Optimizer Hub helm chart will define its own Kubernetes secret objects and use these.
Or you use your existing secrets by:
- Defining the name of your Kubernetes secret object with existingSecret.
- Optionally you can define the name of the keys in your Kubernetes secret object with, e.g. accessKeySecretKey, in case you want something different than what Optimizer Hub expects by default.

Example

For example, if you have an existing secret with S3 credentials, and the name of this K8S secret Object is awsS3secretsForOpthub, it should contain the following values:

 MyKeyID: key123455
MyKey: xyzabcdef

Then you can configure Optimizer Hub with the following values in your values-override.yaml file:

 secrets:
  blobStorage:
    s3:
      existingSecret: awsS3secretsForOpthub
      accessKeySecretKey: MyKeyID
      secretAccessKeySecretKey: MyKey