Skip to main content

Configuring SecureAuth Platform

The SecureAuth platform can be configured with various options to adjust the platform settings to match the business needs.

About Configuring SecureAuth Platform

Any of the reference options can be used in Helm Charts. SecureAuth provides an easy way to provide required parameters via dedicated keys as well as optional ones via the custom config. For secrets, there is a special secret config which could be used to store passwords.

To learn about every available setting, see SecureAuth Configuration Reference.

Required parameters

Those parameters are required for SecureAuth to start succesfully. For datastores, any key from the reference configuration can be provided.

  • Server URL is a public address on which SecureAuth listens for incoming requests

    serverURL: "https://acp.example.com:8443"

  • SQL database

    sql:
  type: "postgresql"
  url: "postgres://root@cockroachdb-public.cockroachdb:26257/acp?sslcert=%2Ftls%2Ftls.crt&sslkey=%2Ftls%2Ftls.key&sslmode=verify-full&sslrootcert=%2Ftls%2Fca.crt"

  • Redis database

    redis:
  addrs:
    - "redis-master.redis:6379"
  redis_search: true
  tls:
    enabled: true
    ca: "/tls/ca.crt"
    key: "/tls/tls.key"
    cert: "/tls/tls.crt"

Optional parameters

Any configuration option from the configuration reference can be provided in this config. It can be merged with default values and the ones provided in other configuration blocks defined here.

config:
  create: true
  name: acp-data
  data:
    logging:
      level: debug

Secrets

It is the same as optional parameters section, but parameters are saved to K8s Secret instead of the ConfigMap.

secretConfig:
  create: true
  name: secret
  data:
    system:
      secret: mysecret

Features

For convenience, SecureAuth feature flags are defined under seperate key. You can specify here any of the features from reference config.

features:
    dev_mode: true
    demo_app: true

You can enable/disable System Features or Tenant Features.

For all available feature flags, check the features section in the Platform Configuration.

System Features

You can enable System feature flags globally for all tenants within the deployment by configuring them in the features section of the Helm Chart.

You can distinguish system feature flags by looking at the comments next to the feature flag looking for (system).

Example:

[...]
  features:
    integration_endpoints: true
    login_with_select_account: false
    script_transformer: true
    admin_workspace_access: false
    system_workspace_access: false
    ciba: true
    token_exchange: true
    webauthn: true
    user_self_registration_improved: true
[...]

Enabling a system feature flag means that the feature is enabled for all tenants within the deployment. For example, if ciba is set to true all tenants can use the Client-Initiated Backchannel Authentication Flow (CIBA).

You can view enabled system features in the Admin Workspace of the System Tenant.

System Tenant Access

For default SecureAuth on Kubernetes deployments, you can find the System Tenant under the https://acp.acp-system:8443/system/admin/app/ URL and login using admin as a username and system tenant secret as the password (found in configuration file under system.secret, n8HF35qzZkmsukHJzzz9LnN8m9Mf97uq by default).

System Features

Tenant Features

Tenant feature flags can be turned on either in the features section of the Helm Chart, or in the Tenant Management view in the Admin Workspace in the System Tenant.

System Tenant Access

For default SecureAuth on Kubernetes deployments, you can find the System Tenant under the https://acp.acp-system:8443/system/admin/app/ URL and login using admin as a username and system tenant secret as the password (found in configuration file under system.secret, n8HF35qzZkmsukHJzzz9LnN8m9Mf97uq by default).

Tenant Features

Enabling a tenant feature flag means only this particular tenant can use the enabled feature.

Advanced parameters

Those parameters are considered for advanced use case or developer mode.

  • Disable TLS in every SecureAuth component. This could be usefull in istio integration where TLS is already provided by envoy.

    tlsDisabled: true

  • If you are using dedicated mTLS ingress, additional listen address must be provided.

    serverURLMtls: "https://mtls.acp.example.com:8443"

  • SecureAuth startup command can be configured. For a full list of parameters, reach out to our support.

    args:
  - server
  - start
  - --metrics

Parameters Merge Order

Parameters are merged from each configuration file including reference config. The order of merge is as following with bottom one taking priority in case of conflict.

  • reference config (part of SecureAuth docker)

  • standalone parameters like redis, sql, features, and more (/data/config.yaml)

  • optional parameters config (/data/extraconfig.yaml)

  • secret config (/secret/config.yaml)

  • environment variables

This is controlled by the configPath parameter with default value of /data/config.yaml,/data/extraconfig.yaml,/secret/config.yaml

Using External Config

In case where you would want to manage secrets on your own, you could do that by disabling secret creation and providing secret name with key config.yaml.

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: secret
stringData:
  config.yaml: |
    system:
      secret: mysecret         
secretConfig:
  create: false
  name: secret

You can customize secret keys or provide multiple keys, it will requires update of configPath.

In this example system.yaml secret will be used as SecureAuth config while cert.key will be mounted under /secret/cert.key for further use.

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: secret
stringData:
  system.yaml: |
    system:
      secret: mysecret    
  cert.key: <data>         
secretConfig:
  create: false
  name: secret
configPath: /data/config.yaml,/data/extraconfig.yaml,/secret/system.yaml
In this section: