[Features] [Discussion] Include host, port, and database name in account secrets

[earayu]

Summary

Currently, when KubeBlocks creates database accounts, the generated secrets only contain username and password fields. It would be helpful to also include connection details like host, port, and database name in the same secret.

Current Behavior

The account secrets generated by KubeBlocks currently look like this:

apiVersion: v1
data:
  password: eTI1YTliMkhENA==
  username: cG9zdGdyZXM=
kind: Secret
# ... metadata
type: Opaque

Proposed Enhancement

Include additional connection parameters in the secret:

apiVersion: v1
data:
  username: cG9zdGdyZXM=
  password: eTI1YTliMkhENA==
  host: <base64-encoded-host>
  port: <base64-encoded-port>  
  database: <base64-encoded-database-name>
kind: Secret

Benefits

1. Simplified application configuration - Applications can get all connection details from a single secret
2. Better developer experience - Reduces the need to manually lookup service endpoints and ports
3. Consistency - Follows patterns used by other database operators in the ecosystem
4. Reduced configuration errors - Less chance of misconfiguring connection parameters

Use Case

When deploying applications that need to connect to KubeBlocks-managed databases, developers currently need to:

1. Get credentials from the account secret
2. Separately lookup the service hostname and port
3. Determine the correct database name

With this enhancement, all connection details would be available in one place.

Questions/Considerations

• How should we handle cases where there are multiple possible hosts (e.g., read/write endpoints)?
• How should we handle cases where there are multiple databases?

I'm not entirely sure if this is the best approach, so I'd love to hear the community's thoughts on this proposal.

[shanshanying]

hi @earayu
we decoupled authdata and connection info from connection credential since v0.9.

Authentication data (username/password) and connection configuration (host/port/database) should be managed separately.

• Storing sensitive data in Secrets (or managed by secret masnager, vault, etc)
• Using Services, Endpoints, or ConfigMaps for non-sensitive configuration

Besides Connection information like host and port should be dynamically provisioned via Kubernetes Services, not hardcoded or duplicated into Secrets. For instance, applications and databases are usually deployed in differnent K8s clusters. and database usually exposes its svc through LB. Such info are not told while provisioning database clusters.