Standard Kubernetes
This page describes how to install and configure Styra DAS On-premises on Standard Kubernetes.
Prerequisites
The following shows the software requirements to install and configure Styra DAS On-premises on Standard Kubernetes.
-
Ensure you have a Kubernetes cluster with version 1.11 or later, with a minimum of six vCPUs and 32 GB of memory.
-
Configure SMTP (Simple Mail Transfer Protocol): An SMTP server allows Styra to send emails. For example, Styra can send an email for user activation, and Styra can also send an email to assist the user for password recovery. During installation, the SMTP information must be specified as listed in the Install and Configure Styra DAS On-Premises on Standard Kubernetes section.
-
You need an SMTP host, SMTP port, SMTP username and password, and SMTP “From” email address.
-
For Gmail, you can create a username or password for your account by clicking App Passwords from Google's security page.
-
-
Styra DAS content security policy requires your browser to connect to Styra DAS through https. This can be configured through either of the following options:
-
HTTPS on the Kubernetes Ingress or LoadBalancer (in conjunction with the Styra DAS Gateway deployment)
-
Use the gateway-tls deployment instead of the gateway
Install and Configure Styra DAS On-Premises on Standard Kubernetes
-
To ensure
kubectl
is pointing to the correct cluster, run:kubectl config get-contexts
-
Download the Styra DAS On-premises YAML configuration files from the Overview page.
-
If you are using the images directly from
registry.styra.com
then configure the cluster nodes to use a private registry with the following command. In this case, skip step #4 and step #5.export REPOSITORY_URL="registry.styra.com"
For more information, see the Overview page.
infoIt is assumed that either the cluster nodes are configured to use a private registry (to use images directly from
registry.styra.com
) OR Docker images are already downloaded from the Overview page and are available in the Cloud Registries (GCP or Azure or AWS). -
Set
REPOSITORY_URL
environment variable to the corresponding image repository URL.export REPOSITORY_URL=<image-repository-url>
Complete the following installation steps with either helm
(recommended) or kubectl
.
Using kubectl
Use the following instructions to install Styra DAS with kubectl
and configure the Kubernetes resources:
-
Modify the YAML files to use the container registry.
TMP_FILE=`mktemp /tmp/on-premises.yaml.XXXXXXXXXX`; sed -e "s/REPOSITORY_URL/$REPOSITORY_URL/" on-premises.yaml > $TMP_FILE; mv $TMP_FILE on-premises.yaml
-
(Optional) Modify the Elasticsearch and Postgres YAML files to use the container registry (if using the bundled Elasticsearch and Postgres).
TMP_FILE=`mktemp /tmp/postgres-deployment.yaml.XXXXXXXXXX`; sed -e "s/REPOSITORY_URL/$REPOSITORY_URL/" postgres/postgres-deployment.yaml > $TMP_FILE; mv $TMP_FILE postgres/postgres-deployment.yaml; \
TMP_FILE=`mktemp /tmp/es-client.yaml.XXXXXXXXXX`; sed -e "s/REPOSITORY_URL/$REPOSITORY_URL/" elastic/es-client.yaml > $TMP_FILE; mv $TMP_FILE elastic/es-client.yaml; \
TMP_FILE=`mktemp /tmp/es-data-stateful.yaml.XXXXXXXXXX`; sed -e "s/REPOSITORY_URL/$REPOSITORY_URL/" elastic/es-data-stateful.yaml > $TMP_FILE; mv $TMP_FILE elastic/es-data-stateful.yaml; \
TMP_FILE=`mktemp /tmp/es-master.yaml.XXXXXXXXXX`; sed -e "s/REPOSITORY_URL/$REPOSITORY_URL/" elastic/es-master.yaml > $TMP_FILE; mv $TMP_FILE elastic/es-master.yaml -
Configure the LoadBalancer IP or NodePort in the DAS
gateway-public
service spec by updating one of the following files.-
(Optional) Add
spec.loadBalancerIP
instandard-external-http/load-balancer-svc.yaml
OR
-
(Optional) Add
spec.ports.nodePort
instandard-external-http/node-port-svc.yaml
.
-
-
Configure settings by modifying
settings.yaml
.-
ingress_url: https://<Cluster Ingress>
-
from_email_address: "YOUR EMAIL ADDRESS"
-
smtp_address: "smtp.gmail.com:PORT NUMBER"
[25 or 465 or 587]
-
-
Configure credentials by modifying
credentials.yaml
.-
smtp_username: "YOUR SMTP USERNAME"
-
smtp_password: "YOUR SMTP PASSWORD"
-
-
(Optional) When the SMTP server is not configured, then a root user must be added, so that you can login after installation to add or update other users.
-
Set the root user and password in environment variables.
export ROOT_USER=<root user email> && export ROOT_USER_PWD=<root user password>
-
Update the
credentials.yaml
with the root user and password.TMP_FILE=`mktemp /tmp/settings.yaml.XXXXXXXXXX`; sed "s/.*config.json.*/ config.json: '{\"tenants\": {\"default\": {\"root_users\": {\"$ROOT_USER\": {\"encrypted_password\": \"\", \"password\": \"$ROOT_USER_PWD\"}}}}}'/" settings.yaml > $TMP_FILE; mv $TMP_FILE settings.yaml
-
-
(Optional) Configure TLS:
-
Update
gateway-tls/deployment.yaml
.TMP_FILE=`mktemp /tmp/gateway-tls-deploy.yaml.XXXXXXXXXX`; sed -e "s/REPOSITORY_URL/gcr.io\/$PROJECT/" gateway-tls/deployment.yaml > $TMP_FILE; mv $TMP_FILE gateway-tls/deployment.yaml
-
Update
credentials.yaml
andsettings.yaml
by mounting thegateway_tls_private_key.pem
andgateway_tls_cert.pem
.data:
gateway_tls_cert.pem: |
<TLS_CERT_CONTENT> -
Similarly, update the secret (
credentials.yaml
) withgateway_tls_private_key.pem
content.data:
gateway_tls_private_key.pem: |
<TLS_KEY_CONTENT> -
Update
gateway-tls/gateway-public-tls-service.yaml
.-
Add
spec.type: LoadBalancer
-
(Optional) Add
spec.loadBalancerIP: <LoadBalancerIP>
OR
-
Add
spec.type: NodePort
-
(Optional) Add
spec.ports.nodePort: <NodePort>
-
-
Install Gateway TLS YAML manifest files with:
kubectl apply -f gateway-tls/
-
-
Install the Elasticsearch and Postgres YAML files (if using the bundled Elasticsearch and Postgres).
for f in elastic/*.yaml postgres/*.yaml; do kubectl apply -f $f; done`
-
a. Install the Styra DAS YAML files.
for f in *.yaml; do kubectl apply -f $f; done
b. Expose the Styra DAS:
-
Using
LoadBalancer
service type:kubectl apply -f standard-external-http/load-balancer-svc.yaml
OR
-
Using
NodePort
service type:kubectl apply -f standard-external-http/node-port-svc.yaml
-
-
Wait until the status on all of the pods is running. To check the status of the pods, run the
kubectl get pods
command. -
Point your browser to
https://<YOUR LoadBalancer IP ADDRESS>
. -
Reset the password for your email address (
from_email_address:
) by using the Forgot Password flow.
The UI can be accessed without a public IP by port-forwarding the port 8080 to the Gateway pod. You can use the kubectl port-forward <YOUR-GATEWAY-POD> 8080:8080
command to access the UI from localhost.
Using Helm
The supported Helm versions are Helm v2.16.1 and Helm v3.
Use the following instructions to install Styra DAS with helm
and configure the Kubernetes resources:
-
Navigate to the charts directory:
cd charts
-
Edit
values.yaml
by using your code editor of choice. The Helm chart provides Helm values and its description. -
Update the values.
email.from_address: "Your-Email"
global.repo: $REPOSITORY_URL
service.loadbalancerip: "LoadBalancerIP"
smtp.username: "username"
smtp.password: "password"
ingress.url: https://<YOUR LoadBalancer IP ADDRESS>
root_user.username: "username"
root_user.password: "password"
-
(Optional) Update the following values.
-
(Optional) If you want to use managed services of Postgres and Elasticsearch update the values as per the instructions in the
values.yaml
. -
(Optional) Similarly, you can configure
s3_decision_streaming
,root_user
credentials,oidc
configuration as per the instructions present under respective sections.
-
-
(Optional) Configure TLS to enable secure HTTPS communication between the cluster ingress and the Styra gateway-secure service.
-
Change the value of
global.tls.enable
totrue
invalues.yaml
. -
Create the
tls
directory understyra-das/
with:mkdir -p styra-das/tls
-
Copy your TLS key and certificate files (with the names
gateway_tls_private_key.pem
andgateway_tls_cert.pem
, respectively) into thetls/
directory by using the following commands.cp <path-to-ssl-cert> styra-das/tls/gateway_tls_cert.pem
cp <path-to-ssl-key> styra-das/tls/gateway_tls_private_key.pem
-
-
(Optional) Configure TLS to enable secure HTTPS communication between the Elasticsearch service and the Styra DAS ES clients (
agentloader
andanalysis-api
services).-
Change the value of
elasticsearch.load_custom_ca
totrue
invalues.yaml
. -
Create the
tls-ca
directory understyra-das/
with:mkdir -p styra-das/tls-ca
-
Copy your custom Certificate Authority (CA) file under the newly created
tls-ca
directory and rename asca-cert-es.pem
with the following command:cp <path-to-tls-ca-file> styra-das/tls-ca/ca-cert-es.pem
-
-
Install the charts directory with:
helm install styra-das styra-das/
tipStoring the hardcoded secrets in
values.yaml
can be avoided by passing the values as arguments while installing the Helm chart. For example, the email and password values for theroot_user
can be set dynamically by using environment variables:export PASSWORD="top-secret"
helm install styra-das styra-das/ --set root_user.email=admin@example.com --set root_user.password=$PASSWORD -
Wait until the status on all of the pods is running. To check the status of the pods, run the
kubectl get pods
command. -
Point your browser to
https://<YOUR LoadBalancer IP ADDRESS>
. -
Reset the password for your email address (
from_email_address:
) by using the Forgot Password flow.
Reference
Helm Values
The following shows the description of various values that can be configured with values.yaml
in the Helm chart for Styra DAS.
# smtp: Configures the SMTP server settings. If SMTP is not used, then
# you must leave "serveraddress" blank ("")
smtp:
serveraddress: smtp.gmail.com:587
username: ""
password: ""
# email.from_address: The user for SMTP server and also the default
# admin user created on installation.
#
# If you have SMTP configured, then you can use the "Forgot Password"
# flow to reset the password and login.
# If SMTP is not configured, then you must set the "root_user" with a
# valid login created during installation.
email:
from_address: support@styra.com
# cluster: For future use. Leave this as "gke" for now.
cluster: gke
# The 'gke.loadbalancerip' field has been deprecated - use 'service.loadBalancerIP' instead
gke:
loadbalancerip: ""
service:
type: LoadBalancer
# (optional) For the LoadBalancer service type, define the public IP that is used to configure Styra public gateway.
loadBalancerIP: ""
# (optional) Specify the nodePort values for the NodePort or LoadBalancer service types.
nodePorts:
http: ""
https: ""
# ingress.url: URL for the ingress.
ingress:
url: https://styra.customer.com
#ddb.enabled: Set to true, if Styra DAS uses the AWS DynamoDB service instead of Postgres, use AWS credentials or enable IRSA.
ddb:
enabled: false
postgres:
# postgres.enabled: Set to false, if managed RDS is used.
enabled: true
db_url: "postgres://postgres/postgresdb?sslmode=disable"
db_username: "postgresadmin"
db_password: "admin123"
# If using AWS managed Postgres, set to `true` to use IAM role authentication. If you are not using role
# based auth, then set the `aws.access_key_id` and `aws.secret_access_key` fields below
db_iam_auth: false
elasticsearch:
# elasticsearch.enabled: Set to false, if managed Elasticsearch
# is used.
enabled: true
# elasticsearch.url: Set the elasticsearch URL if you are using
# managed ES; otherwise, leave it unchanged.
# only effective if "enabled: false".
url: ""
# elasticsearch.username and password enables authentication.
# enabled flag doesn't affect either of them.
username: ""
password: ""
# sniff enables the elasticsearch client calls to the `_nodes/_all/http`
# endpoint in order to keep the state of the ES cluster in sync with the client’s
# connection pool. In a AWS managed ES environment, 'sniff' should be 'true'
sniff: false
# If your Elasticsearch server is secured with a custom CA certificate, then
# copy your CA file under the newly created tls-ca directory using below commands(Rename as below).
# mkdir -p charts/styra-das/tls-ca
# cp <path-to-tls-ca-file> tls-ca/ca-cert-es.pem
# and set `load_custom_ca` to true
load_custom_ca: false
# If using AWS managed ES, set to `true` to use IAM role authentication. If you are not using role
# based auth, then set the `aws.access_key_id` and `aws.secret_access_key` fields below.
aws_iam_role_auth: false
# The following values are used to configure the connection to an AWS managed Elasticsearch instance
aws:
access_key_id: ""
secret_access_key: ""
region: ""
# To Enable the AWS IRSA (fine-grained IAM roles for service accounts), follow the steps
# 1. Update value of "aws_irsa.enabled" to "true"
# 2. Update global.serviceAccountName with the serviceAccount name which is configured with
# desired IAM role. (Note: You can use an existing ServiceAccount or create a new one. In both the cases
# the SA name has to be updated at "global.serviceAccountName".)
irsa:
enabled: false # mandatory
serviceAccount:
# Create the new serviceAccount (Optional: Skip this step if the desired serviceAccount already exists)
# Update the value of "create" to "true"
# Update the values of "aws_account_id" and "aws_iam_role"
create: false
aws_account_id: AWS_ACCOUNT_ID
aws_iam_role: AWS_IAM_ROLE
# s3_decision_streaming: decisions S3 settings for streaming decisions.
s3_decision_streaming:
s3_endpoint: ""
s3_url: ""
s3_region: ""
s3_access_key: ""
s3_secret_access_key_id: ""
s3_iam_role_auth: false
# root_user: Defines a root user which will be created by default as
# admin. Must be set if SMTP is not configured.
# If SMTP is configured, this can be left blank.
root_user:
#root_user.email: Email address of the root user.
email: ""
password: ""
# oidc fields configure the OIDC provider provisioned and enabled.
# oidc.issuer_url is the OIDC issuer URL provided by the provider. For
# example, "https://oidc.customer.com".
# oidc.client_id and client_secret are the credentials provided by the
# provider.
# oidc.allowed_domains is the domains for allowed user accounts, e.g.,
# "customer.com".
# oidc.scopes is the OIDC scopes requirested from the provider. The
# value is an array of strings. If an empty array is provided, then the
# default ["openid", "profile", "email"] is used.
oidc:
id: "OIDC"
issuer_url: ""
client_id: ""
client_secret: ""
allowed_domains: []
scopes: []
# global.repo: Docker image repository URL
global:
# global.repo: Docker image repository URL for Styra images
repo: REPOSITORY_URL
# global.elasticRepo: Docker image repository URL for Elasticsearch images
elasticRepo: REPOSITORY_URL
# global.postgresRepo: Docker image repository URL for Postgres images
postgresRepo: REPOSITORY_URL
# Image pull secrets
imagePullSecrets:
- name: styra-reg
# TLS configurations to enable secure HTTPS communication between the cluster ingress and the Styra `gateway-secure` service.
# mark the "enable: true", and
# create the tls directory under charts/styra-das/
# mkdir -p charts/styra-das/tls
# Copy your tls key and certificate files under the newly created tls/ directory.
# cp <path-to-ssl-cert> tls/gateway_tls_cert.pem
# cp <path-to-ssl-key> tls/gateway_tls_private_key.pem
tls:
enable: false
# Change the value of "serviceAccountName" if you want to deploy Styra DAS's microservices-pods with a custom serviceAccount. Otherwise keep it's value "default"
serviceAccountName: default
# This field should be updated if the cluster version is equal to or greated than 1.20 to avoid file permissions errors.
# kubernetesClusterVersion should be in format <major>.<minor>, dataType: float64. For example
# kubernetesClusterVersion: 1.20
kubernetesClusterVersion:
# If changed to 'true', then all the DAS service pods (including ElasticSearch and Postgres pods) will be compatible to run with istio-proxy sidercar container.
istio:
enabled: false
# To configure DAS pods (Datasources and Systems) network traffic to the outside world via a custom proxy server,
# uncomment and update the properties under `proxyServerEnv` section so that they will be mounted as env variables in the respective containers.
proxyServerEnv: []
# - name: http_proxy
# value: ''
# - name: https_proxy
# value: ''
# - name: no_proxy
# value: ''
# Set true to enable secondary ingress controller
enable_secondary_ingress: false
tenants:
features:
# By default, the decision logs are searchable for three days and retained
# in storage for 14 days. These can be configured by updating below values (e.g., 72h for 3 days).
# `LOG_VIEW_LIMIT_TIME` (for searchable) and `DECISIONS_GC_HISTORY` (for retension)
LOG_VIEW_LIMIT_TIME: "72h"
DECISIONS_GC_HISTORY: "336h"
# Leave empty unless you want to use a second ingress for status and discovery.
SECONDARY_INGRESS_URL:
# Maximum connection lifetime. Leave blank to use default
DATABASE_CONNECTION_MAX_LIFETIME:
# Maximum number of idle connections to the database. Leave blank to use default
DATABASE_MAX_IDLE_CONNECTIONS:
# Maximum number of open connections to the database. Leave blank to use default
DATABASE_MAX_OPEN_CONNECTIONS: