Skip to main content

Styra DAS Installation Prerequisites

The following section describe the Styra DAS Installation Prerequisites.

Local Tools​

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​

Kubectl is a command line tool for accessing and interacting with Kubernetes clusters. SeeKubernetes Install Tools for installation instructions.

Helm 3​

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.

External Dependencies​

Load Balancer​

Styra DAS requires both a cloud-provider provisioned LoadBalancer and Kubernetes-side configuration to make Styra DAS available to incoming network requests.

Elasticsearch​

Styra DAS requires Elasticsearch, and will manage the installation of it for you via the Styra DAS Helm chart. If you would prefer to manage Elasticsearch yourself, you are free to do so. There is an option in the values file to turn off managed Elasticsearch.

(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.

From File​

note

Providing custom CA certificates to the Styra DAS Helm chart using fromFile 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 using a certificate file:

  1. Create a tls folder in the styra-das chart directory.
  2. Copy the PEM encoded certificate into this folder. The certificate must be named custom-ca.crt.
  3. Set customCA.enabled in values.yaml to true.
  4. Set customCA.fromFile in values.yaml to true.

From Values​

To supply Styra DAS with a CA certificate from the values file:

  1. Set customCA.enabled in values.yaml to true.
  2. Set customCA.fromValues in values.yaml to true.
  3. Set customCA.certificates to the desired certificate values in values.yaml.

Proxy Settings​

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.

Secret Configuration​

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:

  • deploySecrets
  • secretNames
  • externalSecrets

The following sections will describe what each of these configuration options controls, as well as the situations that might necessitate their use.

Deploy Secrets​

The 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 deploySecrets.enabled to false will prevent the Helm chart from creating Kubernetes Secrets. Setting deploySecrets.enabled to 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:

deploySecrets:
 enabled: false

Secret Names​

The 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 credentials, postgres, and gateway-tls Secrets.

secretNames:
 # mandatory secrets
 credentials: "styra-creds-us-east-1"
 postgres: "styra-postgres-us-east-1"

 # optional secrets:
 # will be unused if `gateway.tls: false`
 gatewayTLS: "mydomain-tls-cert-us-east-1"
 # will be unused if `gatewaySecondary.tls: false`
 gatewaySecondaryTLS: ""
 ....

deploySecrets:
 enabled: false

External Secrets​

The externalSecrets configuration can be used to remove all Secret volumeMounts from Styra DAS deployments.

Setting externalSecrets to 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:

deploySecrets:
 enabled: false

externalSecrets: true