lensesAgent:
storage:
postgres:
enabled: true
host: postgres-postgresql.postgres.svc.cluster.local
port: 5432
database: lensesagent
username: lenses
password: external # use "external" to manage it using secrets
additionalEnv:
- name: LENSES_STORAGE_POSTGRES_PASSWORD
valueFrom:
secretKeyRef:
name: [SECRET_RESOURCE_NAME]
key: [SECRET_RESOURCE_KEY]
2
Configure HQ connection (agent key)
Connection to Lenses HQ is a straight forward process which requires two steps:
Creating Environment and obtaining AGENT KEY inHQ as described here, if you already have not done so;
Storing that same key in Vault or as a K8s secret.
The agent communicates with HQ via a secure custom binary protocol channel. To establish this channel and authenticate the Agent needs and AGENT KEY.
Once the AGENT KEY has been copied, store it inside of Vault or any other tool that has integration with Kubernetes secrets.
There are three available options how the agent key can be used:
ExternalSecret via External Secret Operator (ESO)
Pre-created secret
Inline string
To use this option, the External Secret Operator (ESO) has to be installed and available for usage in K8s cluster your are deploying Agent.
When specifying secret.type: "externalSecret", thechart will:
create an ExternalSecretin the namespace where Agent is deployed;
a secret is mounted for Agent to use.
values.yaml
lensesAgent:
hq:
agentKey:
secret:
type: "externalSecret"
# Secret name where agentKey will be read from
name: hq-password
# Key name under secret where agentKey is stored
key: key
externalSecret:
additionalSpecs: {}
secretStoreRef:
type: ClusterSecretStore # ClusterSecretStore | SecretStore
name: [secretstore_name]
Make sure that secret you are going to use is already created in namespace where Agent will be installed.
values.yaml
lensesAgent:
hq:
agentKey:
secret:
type: "precreated"
# Secret name where agentKey will be read from
name: hq-password
# Key name under secret where agentKey is stored
key: key
This option is NOT for PRODUCTION usage but rather just for demo / testing.
The chart will create a secret with defined values below and the same secret will be read by Agent to connect to HQ.
values.yaml
lensesAgent:
hq:
agentKey:
secret:
type: "createNew"
# Secret name where agentKey will be read from
name: "lenses-agent-secret-1"
# Value of agentKey generated by HQ
value: "agent_key_*"
This secret will be fed into the provisioning.yaml. The HQ connection is specified at line 30, below, where reference ${LENSESHQ_AGENT_KEY} is being set:
values.yaml
lensesAgent:
provision:
path: /mnt/provision-secrets
connections:
lensesHq:
- name: lenses-hq
version: 1
tags: ['hq']
configuration:
server:
value: [LENSES_HQ_FQDN_OR_IP]
port:
value: 10000
agentKey:
# This property shouldn't be changed as it is mounted automatically
# based on secret choice for hq.agentKey above
value: ${LENSESHQ_AGENT_KEY}
sslEnabled:
value: false
In order to enable TLS for secure communication between HQ and the Agent please refer to the following part of the page.
More about provisioning and more advanced configuration options for each of these components can be found on the following link.
4
Cluster RBACs
The Helm chart creates Cluster roles and bindings, that are used by SQL Processors, if the deployment mode is set to KUBERNETES. They are used so that Lenses can deploy and monitor SQL Processor deployments in namespaces.
To disable the creation of Kubernetes RBAC set: rbacEnabled: false
If you want to limit the permissions the Agent has against your Kubernetes cluster, you can use Role/RoleBinging resources instead. Follow this link in order to enable it.
If you are not using SQL Processors and want to limit permissions given to Agent's ServiceAccount, there are two options you can choose from:
rbacEnable: true - will enable the creation of ClusterRole and ClusterRoleBinding for service account mentioned above;
rbacEnable: true and namespaceScope: true - will enable the creation of Role and RoleBinding which is more restrictive;
(Optional) Enable TLS connection with HQ
In this case, TLS has to be enabled on HQ. In case you haven't yet enabled it, you can find details here to do it.
Enabling TLS in communication between HQ is being done in the provisioning part of values.yaml.
In order to successfully enable TLS for the Agent you would need to:
additionalVolume & additionalVolumeMounts - with which you will mount truststore with CA certificate that HQ is using and which Agent will need to successfully pass the handshake.
additionalEnv - which will be used to securely read passwords to unlock truststore.
Be aware that for the time being and alpha purposes usage of --version is mandatory when deploying Helm chart through Helm repository.
Example Values files
Be aware that example of values.yaml shows only how all parameters should look at the end. Please fill them with correct values otherwise Helm installation might not be successful.
Example of values.yaml
values.yaml
lensesAgent:
storage:
postgres:
enabled: true
host: [postgres.url]
port: 5432
username: postgres
password: changeMe
database: agent
hq:
agentKey:
secret:
type: "createNew"
name: "agentKey"
value: "agent_key_*"
provision:
path: /mnt/provision-secrets
connections:
lensesHq:
- name: lenses-hq
version: 1
tags: ['hq']
configuration:
server:
value: hq-tls-test-lenses-hq.hq-agent-test.svc.cluster.local
port:
value: 10000
agentKey:
value: ${LENSESHQ_AGENT_KEY}
kafka:
# There can only be one Kafka cluster at a time
- name: kafka
version: 1
tags: ['staging', 'pseudo-data-only']
configuration:
kafkaBootstrapServers:
value:
- PLAINTEXT://kafka-1.svc.cluster.local:9092
- PLAINTEXT://kafka-2.svc.cluster.local:9092
protocol:
value: PLAINTEXT
# Metrics are strongly suggested for better Kafka cluster observability
metricsType:
value: JMX
metricsPort:
value: 9581