Configure Feature Flags
The following sections describe how to configure feature flags.
The version 2 of the Styra DAS authorization will give you more fine-grained controls as well as new RBAC roles scoped for Workspace, System, and Stack resources.
Additionally, there are new capabilities such as SSO-claims based authorization as well the ability to grant permissions to specific API tokens.
Upon successful migration, the Styra DAS UI will automatically render new Access Control pages which can be used for further configuration of Styra DAS Authorization posture for the tenant.
Modifying these feature flags can break external workflows if they are based on a specific version of the authorization APIs, for example, creating users through the Styra DAS API.
To enable version 2 of Styra DAS product authorization, uncomment the following Feature Flags which will automatically trigger a data migration and enable all the new capabilities and UI pages.
# authz v2
# AUTHZ_MAX_LOAD_DELAY: 1m
# AUTHZ_V2_ENABLED: true
# AUTHZ_V2_ENFORCEMENT_ENABLED: true
# AUTHZ_ENFORCEMENT_ENABLED: false
# AUTHZ_V2_INTERNAL_APIS_ENABLED: true
# AUTHZ_V2_EXPANDED_ROLES_ENABLED: true
There are two Feature Flags for Elasticsearch settings:
- LOG_VIEW_LIMIT_TIME which configures the max decision log record age.
- DECISIONS_GC_HISTORY which configures how long decision batches are stored before they expire.
The default settings in values.yaml are:
Postgres connections limit
You can limit the connection lifetime, as well as the number of idle and open connections to the database by setting them in
# postgres connection settings
value is a positive integer. If not set, the default of 2 maximum idle connections and an unlimited number of open connections are used.
After SSO is configured and validated, local login can be disabled through a feature flag. This can be configured by uncommenting the
feature flag in the
featureFlags section of
# disable local users
Secondary ingress URL
SECONDARY_INGRESS_URL feature flag can be used in conjunction with the
gatewaySecondary configuration section to deploy a secondary ingress. Please refer to
Configure a Second Ingress for more information on the use case for this feature, as well as information on how to
best configure it.