Styra DAS Installation Prerequisites
The following section describe the Styra DAS Installation Prerequisites.
Self-Hosted Styra DAS requires that two tools, kubectl and Helm, be installed on your local machine in order to deploy Styra DAS to your target Kubernetes cluster. This section will contain brief descriptions of the tools, as well as link to instructions for downloading them.
Kubectl is a command line tool for accessing and interacting with Kubernetes clusters. SeeKubernetes Install Tools for installation instructions.
Helm is a tool for packaging, managing, and installing sets of Kubernetes manifests. Helm is the primary installation tool for Self-Hosted Styra DAS, which is distributed as a Helm chart. SeeInstalling Helm for installation instructions.
(Optional) Enterprise Settings
There are optional enterprise settings which can be installed with Styra DAS.
Custom CA Certificates
In some customer environments, Styra DAS may need to communicate with TLS-secured services for which certificates have been issued by a custom certificate authority (CA). This is used when Styra DAS needs to interact with a third-party service that is running on self-hosted infrastructure on an internal Version Control System (such as Gitlab), or an internally configured SSO service (such as internal LDAP). In these instances, Styra DAS requires the root CA certificate in order to validate any connections it needs to make to the third-party services.
Providing custom CA certificates to the Styra DAS Helm chart will require utilizing the Installing From Local System installation path, as opposed to Installing From Styra’s Helm Repository. This is because the charts must be pulled down to a local system in order to make the
custom-ca.crt file available during Styra DAS installation.
To supply Styra DAS with the root CA certificate:
- Create a
tlsfolder in the styra-das chart directory.
- Copy the PEM encoded certificate into this folder. The certificate must be named
truewhen Customizing Values.
When running in Kubernetes clusters with locked down egress, it can be necessary to configure Styra DAS to send any outbound network requests through a proxy. This can be done by uncommenting and configuring the
proxy section in
values.yaml when Customizing Values.
By default the Self-Hosted Styra DAS Helm chart will create several Kubernetes secrets, as well as their corresponding volumeMounts in chart-generated Deployments. The secrets contain configuration that is necessary for Styra DAS operations, but also sensitive in nature, such as PostgreSQL credentials.
You can also manage Kubernetes Secret creation or mounting through non-Helm tooling. Styra has made this possible through three configuration options in
values.yaml. These options are:
The following sections will describe what each of these configuration options controls, as well as the situations that might necessitate their use.
deploySecrets setting indicates whether the Styra DAS Helm chart should create Kubernetes Secrets. By default, this is set to
true, indicating that the chart should create all Secrets needed for Styra DAS operation. Setting
false will prevent the Helm chart from creating Kubernetes Secrets. Setting
false can be useful when the user wishes to use other tools to create or deploy the Secrets.
The following configuration would disable Kubernetes Secret creation during installation:
secretNames configuration can be used to override the names the Helm chart will use for Kubernetes Secrets and their corresponding VolumeMounts. This section is used with automation-generated secrets that may have a different naming convention than that typically expected by Styra DAS.
The following configuration example would override the name of the
# mandatory secrets
# optional secrets:
# will be unused if `gateway.tls: false`
# will be unused if `gatewaySecondary.tls: false`
externalSecrets configuration can be used to remove all Secret volumeMounts from Styra DAS deployments.
true will remove all Secret volumeMounts from generated Deployments and Pods. This requires an external system to provide secret values to Styra DAS services.
The following configuration example would prevent the Helm chart from either creating or mounting Kubernetes Secrets: