Security

This section describes how security, authentication, and authorization are managed in HCL Link when deployed in a cloud-native environment.

Authentication

HCL Link supports two authentication methods, configured in the values.yaml file.

Built-in User Repository (Default)
- Description: Uses an internal user repository stored in MongoDB.
- Behavior: Link manages users, credentials, and roles internally.
- Configuration: Enabled by default. No setup required.
Keycloak Integration
Integrate HCL Link with Keycloak for Single Sign-On (SSO) and centralized identity management.
- How it works: Login requests are redirected to Keycloak. After authentication, Keycloak returns a signed token to Link for session creation.
- Setup Steps:
  - In Keycloak: Create a realm, a client for HCL Link, and assign roles.
  - In HCL Link: Enable integration and provide Keycloak connection details.
```
# values.yaml
keycloak:
  enabled: true
  serverUrl: "https://my-keycloak.example.com/auth"
  realmId: "my-link-realm"
  clientId: "hcl-link-client"
  # 'secret' refers to the name of a Kubernetes secret you create
  # containing the 'clientSecret' for the Keycloak client.
  secret: "link-keycloak-client-secret"
```

Default Administrator Account

When Link is installed, a default admin account is created with a randomly generated password stored in a Kubernetes secret.

Retrieve the password:

kubectl get secrets/{{ include "lnk-product.fullname" . }}-login-secret 
--namespace {{ .Release.Namespace }} 
--template='{{ "{{ .data.password | base64decode }}" }}'

You can change the password after login.

If MongoDB is external or uses persistent data, existing admin credentials remain unchanged. To use a custom password, create a secret and reference it in values.yaml:

kubectl create secret generic link-login-secret --from-literal=password=mypassword

Then provide the name of the secret as the value of server.initialLogin.secret in your values.yaml.

Authorization (User Roles)

HCL Link uses a simple and clear authorization model with two primary roles:

Administrator: This role has full permissions across the entire application. Administrators can manage users, configure system settings, create and manage connections, and build and deploy flows.
User: This is a standard user role. Users can typically create, edit, and run flows and other design assets but cannot access system-wide administrative settings or manage other users.

Secrets Management

HCL Link relies on Kubernetes Secrets to manage all sensitive information, ensuring that passwords, keys, and other credentials are not stored in plain text in the values.yaml.

Container Registry: To pull the HCL Link images from the private hclcr.io registry, you need to provide an image pull secret. Configure this secret globally in the values.yamlfile.

# values.yaml
global:
  # The name of the 'kubernetes.io/dockerconfigjson' secret
  # that holds your credentials for hclcr.io
  hclImagePullSecret: "hclcr-secret"

Application and TLS Secrets

All passwords and TLS certificates are stored in Kubernetes secrets. Create the secret first, and then configure the chart to reference it.

# values.yaml
client:
  inbound:
    protocol: "httpss"
    # The name of the kubernetes.io/tls secret
    secret: "link-client-tls-secret"

server:
  inbound:
    https:
      enabled: true
      # The name of the kubernetes.io/tls secret
      secret: "link-server-tls-secret"

Kafka Security Secrets Configuration

For the kafka-link component, Kafka authentication supports both SASL and SSL/TLS mechanisms. Enable the required settings in the kafkaLink section of your values.yaml file, and provide the necessary Kubernetes secrets as described below.

SSL/TLS Authentication

The secret must include the following keys:

Table 1.
Key	Value
kafka.client.truststore.jks	Java truststore file
kafka.client.keystore.jks	Java keystore file (optional if one-way SSL)
truststore-password	Password for the truststore
keystore-password	Password for the keystore
key-password	Password for the key

Create the secret by running the following command, replacing [secret-name] with your secret’s name:

kubectl create secret generic [secret-name] \
  --from-file=kafka.client.truststore.jks=kafka.client.truststore.jks \
  --from-file=kafka.client.keystore.jks=kafka.client.keystore.jks \
  --from-literal=truststore-password='password' \
  --from-literal=keystore-password='password' \
  --from-literal=key-password='password'

SASL Authentication

HCL Link supports SASL authentication with or without SSL and Kerberos. The required Kubernetes secret configuration varies based on your setup.

SASL with SSL

The secret must include the following keys:


Key	Value
`kafka.client.truststore.jks`	Java truststore file
`truststore-password`	Password for the truststore
`kafka_client_jaas.conf`	JAAS configuration file
`krb5.conf`	krb5.conf Kerberos configuration (if used)

Create the secret (replacing [secret-name]) as follows:

kubectl create secret generic [secret-name] \
  --from-file=kafka.client.truststore.jks=kafka.client.truststore.jks \
  --from-literal=truststore-password='password' \
  --from-file=kafka_client_jaas.conf=kafka_client_jaas.conf \
  --from-file=krb5.conf=krb5.conf

SASL without SSL (Kerberos not used)

The secret must include the following key:


Key	Value
`kafka_client_jaas.conf`	JAAS configuration file

Create the secret (replacing [secret-name]) as follows:

kubectl create secret generic [secret-name] \
  --from-file=kafka_client_jaas.conf=kafka_client_jaas.conf

SASL without SSL (if Kerberos used)

The secret must contain the following keys:


Key	Value
kafka_client_jaas.conf	JAAS configuration file
krb5.conf	krb5.conf Kerberos configuration

Create the secret (replacing [secret-name]) as follows:

kubectl create secret generic [secret-name] \
  --from-file=kafka_client_jaas.conf=kafka_client_jaas.conf \
  --from-file=krb5.conf=krb5.conf

TLS and Mutual TLS (mTLS)

TLS: Transport Layer Security (TLS) is configured by setting the protocol to https for inbound services (such as clients and servers) and specifying the name of a TLS secret, as described earlier. This encrypts all traffic between the user’s browser or API client and the application.
Mutual TLS (mTLS): HCL Link does not manage mTLS directly. mTLS is an advanced security mechanism where both the client and server present valid certificates to authenticate each other. It is typically configured at the infrastructure level rather than in the application. You can enable mTLS using one of the following:
- Ingress Controller: Configure NGINX, Emissary-ingress, or similar controllers to require a client certificate.
- Service Mesh: Use tools like Istio or Linkerd to manage mTLS for all pod-to-pod communication within the cluster.

Network Security

CORS (Cross-Origin Resource Sharing)

CORS is a browser security feature that prevents web pages from requesting resources from a different domain. The HCL Link client UI is protected by CORS. To allow trusted web applications (for example, a custom dashboard) to access the Link API, add their origins to the allow list in the values.yaml file.

# values.yaml
client:
  headers:
    # A list of URLs to allow cross-origin content from.
    # Example:
    # crossOriginAllowedUrls:
    #   - "httpss://my-dashboard.example.com"
    crossOriginAllowedUrls: []

IP Blacklists and Firewalls

HCL Link does not include a built-in application-level IP blacklist. This control is managed at the network level through:

Kubernetes Network Policies: Define which pods can communicate with each other.
Ingress Controller: Configure it to allow or block traffic based on source IP.
Cloud Provider Firewalls / WAF: Use security groups, VPC firewalls, or a Web Application Firewall (WAF) to block malicious traffic before it reaches the cluster.