Skip to main content
Version: v1.6.1

ConfigMap YAML Specification

potctl allows users to deploy and manage configMaps.

The configMap has a very simple definition

apiVersion: datasance.com/v3
kind: ConfigMap
metadata:
name: test-configMap
spec:
immutable: false
data:
key1: value1
key2: value2
apiVersion: datasance.com/v3
kind: ConfigMap
metadata:
name: test-nats-configmap
spec:
immutable: true
data:
accounts.conf: |
accounts: {
USERS: {
users: [
{user: test, password: test}
],
jetstream: enabled
}
}
nats-server.conf: |
port: 4222
server_name: test-leaf
jetstream {
store_dir="./store_leaf"
domain: test
}
leafnodes {
remotes = [
{
urls: ["nats://test:test@example.online:7422"]
account: "USERS"
tls: {
ca_file: "/etc/nats/certs/leafnodes/ca.crt"
cert_file: "/etc/nats/certs/leafnodes/tls.crt"
key_file: "/etc/nats/certs/leafnodes/tls.key"
verify: true
handshake_first: true
}
},
]
}
mqtt {
port: 1884
}
FieldDescription
spec.immutableIs configMap immutable? true or false
spec.useVaultOptional. When true, ConfigMap values can be resolved from a vault backend instead of static data.
dataConfigMap data with key value pairs (or vault references when useVault is enabled).

Vault integration

ConfigMap supports vault integration so that sensitive or dynamic values can be pulled from an external secrets store instead of storing them literally in the spec. When useVault (or the equivalent option) is enabled, the Controller can resolve ConfigMap keys from supported backends, including:

  • HashiCorp Vault
  • OpenBao
  • AWS Secrets Manager
  • Google Secret Manager
  • Azure Key Vault

Configuration for vault connection (endpoint, auth, path) is typically provided via Controller configuration or environment variables. Refer to the Controller documentation for the exact vault-related settings.

Group 3See anything wrong with the document? Help us improve it!