Skip to main content

Amazon Web Services

The following section provides guidance on installing Self-Hosted Styra DAS on Amazon Web Services (AWS).

Kubernetes Cluster​

AWS uses Amazon Elastic Kubernetes Service (Amazon EKS). Amazon EKS is a managed Kubernetes service on AWS for self-hosted environments.

See Getting started with Amazon EKS for additional information on installing and configuring Amazon EKS. Styra DAS microservices require about 20 vCPU. Ensure that there's enough computing power available.

External Dependencies​

AWS EBS CSI Driver​

Several Styra DAS microservices depend on the AWS EBS CSI Driver. If you are creating a cluster from scratch, or use Terraform for resource management, you can easily add this deployment using cluster_addons. For more information you can look at Terraform's EKS example which adds the EBS CSI Driver to an EKS cluster during creation.

If you are using eksctl for cluster creation, instructions for adding EBS CSI Driver as an addon can be found here.

If you would prefer to manage the installation of the EBS CSI Driver yourself, instructions can be found here.

Data Store​

Self-Hosted Styra DAS supports two data store options for AWS:

  • Amazon RDS for PostgreSQL
  • Amazon DynamoDB with S3

The data store will store decision records, policy files, configuration files, and more.

Amazon RDS for PostgreSQL​

This section provides information on configuring Amazon RDS for PostgreSQL for use with Self-Hosted Styra DAS.

Styra DAS supports three methods of authentication with Amazon RDS:

  • Password Authentication (Amazon RDS default)
  • AWS IAM User (Optional)
  • AWS IAM Role (Optional)

The following section, “RDS Instance Creation,” describes the initial setup of an RDS instance, which requires setting up a root username and password. The section afterward, “AWS IAM User/Role Access” covers additional steps for enabling IAM authentication between Self-Hosted Styra DAS and RDS.

Creating an RDS Instance​

The following section configures Amazon RDS with Styra DAS.

note

It is recommended to configure your RDS instance in the same VPC as the EKS cluster where Styra DAS will be installed, which makes network connectivity much easier. Styra DAS can work with an RDS instance in a separate VPC but requires you to set up your Security Groups so that Styra DAS can connect to the RDS instance.

RDS Instance Creation has the following prerequisites:

  • VPC ID
  • VPC Security Groups
  • Secure Username and Password
  1. Create the configuration for a new RDS instance. See Creating a PostgreSQL DB Instance for additional information.
  2. Allocate a minimum of 250 GB to ensure enough room for decision storage.
  3. (Optional) Enable Storage autoscaling. Autoscaling can prevent service outages due to insufficient storage but can also incur additional costs in the event of a scale-up.
  4. Enter a username and password to act as the root user of the PostgreSQL database. PostgreSQL requires a root user to be defined at setup, even if you plan to rely on an IAM User or Role for authentication.
  5. In Connectivity, select the VPC ID used with the associated EKS instance and the VPC Security Groups. If you would prefer to not have the cluster and database in the same VPC you can place them in separate VPC's and set up a VPC Peering Connection.
  6. In Database authentication, select Password authentication to use password authentication between Styra DAS and Amazon RDS, or Password and IAM database authentication to configure an IAM User or Role. If you choose to use password authentication then, after validating your connection in the next section, you can jump down to the Ingress section.

(Optional) Validate Network Connectivity​

After your RDS instance has come online, test the network connection between your EKS cluster and the RDS instance.

  1. Spin up a Postgres pod in your cluster and test the connection to RDS using psql. 
    kubectl run rds-connection-test-pod \
    --image postgres \
    --command sleep infinity
  2. Monitor the progress of the pod creation, using the following command: 
    kubectl get pods --watch
  3. After the rds-connection-test-pod pod shows as Running, open an interactive session in the pod using the following command: 
    kubectl exec -it rds-connection-test-pod -- /bin/bash
  4. From the pod, use the root user username, password, and the address of the Amazon RDS instance to test your connection to your database. See Connecting to an Amazon RDS DB instance for additional information for finding the RDS endpoint. If you have changed the default database identifier from postgres to a custom value, you will need to add the -d <database identifier> flag to the command. 
    PGPASSWORD=<POSTGRES_ROOT_USER_PASSWORD> psql \
    -h <RDS_DB_ENDPOINT> \
    -U <POSTGRES_ROOT_USERNAME>
  5. Verify the psql connection to the Postgres database is open by confirming postgres=> is displayed on the left side of the terminal.
  6. Exit the psql connection and exit the pod interactive session. Delete the test pod using the following command: 
    kubectl delete pod rds-connection-test-pod

This configures the use of a Postgres username and password for Styra DAS to authenticate with Amazon RDS. Supply the root user’s username and password during Configuration and Installation. If you only want to use the username and password to authenticate, you can jump down to the Ingress section.

AWS IAM User and Role Configuration​

Styra DAS can use IAM authentication when communicating with a backing RDS instance. IAM database authentication for MariaDB, MySQL, and PostgreSQL provides additional information on setup and configuration. The following steps cover the initial configuration of the PostgreSQL database and creating an IAM policy for RDS access.

  1. Create a non-root PostgreSQL user to act as a target for IAM user assumption. Connect to your RDS instance with psql (using the root user), and run the SQL commands in the following steps. You can set STYRA_POSTGRES_USER to any value. The best practice is to select an alphabetic lowercase name, without dashes or underscores.
  2. Create a database user for Styra DAS by executing the following SQL command. 
    CREATE USER `STYRA_POSTGRES_USER`;
  3. Grant privileges to the user by executing the following SQL command. 
    GRANT ALL PRIVILEGES ON DATABASE postgres TO `STYRA_POSTGRES_USER`;
  4. Enable AWS RDS login by executing the following SQL command. 
    GRANT rds_iam TO `STYRA_POSTGRES_USER`;
    note

    Adding this role to your user will make it incapable of authenticating using a username and password, you will only be able to use the IAM authentication.

  5. Create an IAM policy for use with the IAM entity you choose to use for authentication. Follow Creating IAM Policies to create a new policy, and refer to Creating and Using an IAM Policy for IAM database access to determine the policy body. The following documentation will refer to this created policy as STYRA_RDS_IAM_POLICY.

Once the PostgreSQL user creation and IAM policy creation are complete, complete the steps for the AWS IAM User or AWS IAM Role as appropriate.

IAM User​

Styra DAS can be configured to use an IAM User to assume the STYRA_POSTGRES_USER in your RDS instance. The following steps cover how to properly configure the IAM User for use with Styra DAS.

  1. Create an AWS IAM User. See Creating an IAM User in your AWS account for additional information.
  2. Create an access key/secret access key pair under “Security Credentials” of the User. Both keys will be needed for Configuration and Installation. This creates the STYRA_IAM_USER_ACCESS_KEY and STYRA_IAM_USER_SECRET_KEY.
  3. Attach the STYRA_RDS_IAM_POLICY IAM policy to the newly created IAM User.

Once the preceding steps are complete, the IAM User is configured for use with Styra DAS. When you proceed to Configuration and Installation, supply the IAM User’s access key and secret access key under aws.access_key_id and aws.secret_access_key, respectively.

IAM Role​

Styra DAS can be configured to use an IAM Role to assume the STYRA_POSTGRES_USER in your RDS instance. The following steps cover how to properly configure the IAM Role for use with Styra DAS.

  1. Create an AWS IAM Role. See Creating IAM roles for additional information. Leave the trust relationship policy empty, as it will be configured in the following steps. The IAM Role will be referred to as STYRA_IAM_ROLE.
  2. Locate the OpenID OIDC Provider URL for your EKS cluster. This is used to construct the trust relationship policy of the IAM Role.
    1. Navigate to Amazon Elastic Kubernetes Service in the AWS Web Console.
    2. Select Clusters in the navigation bar.
    3. Click into the details of the EKS cluster where you plan to deploy Styra DAS.
    4. Find the full provider URL in Overview > Details > OpenID > Connect provider URL.
    5. Remove the HTTPS:// prefix from the URL.
    6. Save the resultant value to replace the three instances of OIDC_PROVIDER_URL in a following step.
  3. Specify a Kubernetes ServiceAccount name for use with Styra DAS. The recommendation is styra-das, which is the default value in the Helm Chart’s values.yaml file. If you use another value, you will have to update the top-level serviceAccount field to match during Configuration and Installation. Use the ServiceAccount name to replace the STYRA_DAS_SERVICE_ACCOUNT field in the policy file below.
  4. Replace all templated values in the following policy template and save the result as a local policy file. 
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/<OIDC_PROVIDER_URL>"
          },
          "Action": "sts:AssumeRoleWithWebIdentity",
          "Condition": {
            "StringEquals": {
              "<OIDC_PROVIDER_URL>:aud": "sts.amazonaws.com",
              "<OIDC_PROVIDER_URL>:sub": "system:serviceaccount:<STYRA_DAS_NAMESPACE>:<STYRA_DAS_SERVICE_ACCOUNT>"
            }
          }
        }
      ]
    }
  5. Attach the completed policy to the STYRA_IAM_ROLE.

Once the preceding steps are complete, the IAM Role should be ready for use with Styra DAS. When you proceed to Configuration and Installation, ensure that the top-level serviceAccount field in your values.yaml file matches the STYRA_DAS_SERVICE_ACCOUNT used in the STYRA_IAM_ROLE trust policy.

Amazon DynamoDB with S3​

When running in AWS, Self-Hosted Styra DAS can use Amazon DynamoDB in conjunction with S3 as an alternative to a PostgreSQL database. You may want to choose DynamoDB and S3 to automatically scale the database when the number of decisions flowing through Styra DAS increases.

When using DynamoDB with S3 as a data store, Styra DAS will create all the necessary DynamoDB tables and S3 buckets. It will also attempt to auto-heal the generated tables and bucket objects to the best of its ability, overriding manual changes.

AWS offers two DynamoDB authentication options supported by Styra DAS:

  • AWS IAM User
  • AWS IAM Role

IAM User and Role Setup​

The following steps are required to use Styra DAS with DynamoDB and S3 as a data store. This section will cover setup steps that are required regardless of whether you use a User or Role.

The following steps will require replacing variables in templated IAM policies to create policies that will work in your environment. The variables that will be used are:

  • <AWS_REGION>: Represents the AWS region where you will be running Styra DAS. This will be the same region where you are running your EKS cluster and should have a format resembling us-east-1 or us-west-2. For more information on AWS Region values, refer to Regions, Availability Zones, and Local Zones.
  • <AWS_ACCOUNT_ID>: Represents the AWS Account in which you will be running Styra DAS. Should be a numeric ID value.
  • <STYRA_RESOURCE_PREFIX>: Corresponds to the top-level resourcePrefix value in values.yaml. Reminder: AWS S3 bucket names must be globally unique across all AWS regions and accounts. One way to ensure this is to include the AWS account number and region in the prefix, in addition to an application or environment identifier (e.g., “012345678901-us-east-1-DAS-prod”).
  1. Create an IAM Role named DynamoDBAutoscaleRole, which will be passed to the DynamoDB service to allow Table autoscaling.
  2. Use the following JSON to create the DynamoDBAutoscaleRole Role’s permission body. 
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "dynamodb:DescribeTable",
            "dynamodb:UpdateTable"
          ],
          "Resource": [
            "arn:aws:dynamodb:<AWS_REGION>:<AWS_ACCOUNT_ID>:table/<STYRA_RESOURCE_PREFIX>*"
          ]
        },
        {
          "Effect": "Allow",
          "Action": [
            "cloudwatch:PutMetricAlarm",
            "cloudwatch:DescribeAlarms",
            "cloudwatch:GetMetricStatistics",
            "cloudwatch:SetAlarmState",
            "cloudwatch:DeleteAlarms"
          ],
          "Resource": [
            "arn:aws:cloudwatch:<AWS_REGION>:<AWS_ACCOUNT_ID>:alarm:*"
          ]
        }
      ]
    }
  3. Use the following JSON as the DynamoDBAutoscaleRole Role’s trust relationship. 
    {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Effect": "Allow",
              "Principal": {
                  "Service": "dynamodb.application-autoscaling.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
          }
      ]
    }
  4. Create an IAM Policy to allow Styra DAS to create and manage DynamoDB tables, indexes, and records. Replace the variables in the following policy template, then add it to a new IAM Policy in your AWS Account. The IAM policy will be referred to as STYRA_DYNAMODB_ACCESS_POLICY going forward. 
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "dynamodb:BatchGetItem",
            "dynamodb:BatchWriteItem",
            "dynamodb:ConditionCheckItem",
            "dynamodb:CreateTable",
            "dynamodb:DeleteItem",
            "dynamodb:DeleteTable",
            "dynamodb:DescribeContinuousBackups",
            "dynamodb:DescribeTable",
            "dynamodb:DescribeTimeToLive",
            "dynamodb:GetItem",
            "dynamodb:ListTagsOfResource",
            "dynamodb:PutItem",
            "dynamodb:Query",
            "dynamodb:Scan",
            "dynamodb:TagResource",
            "dynamodb:UpdateContinuousBackups",
            "dynamodb:UpdateItem",
            "dynamodb:UpdateTable",
            "dynamodb:UpdateTimeToLive"
          ],
          "Resource": [
            "arn:aws:dynamodb:<AWS_REGION>:<AWS_ACCOUNT_ID>:table/<STYRA_RESOURCE_PREFIX>*"
          ]
        },
        {
          "Effect": "Allow",
          "Action": [
            "dynamodb:ListTables"
          ],
          "Resource": [
            "arn:aws:dynamodb:<AWS_REGION>:<AWS_ACCOUNT_ID>:table/*"
          ]
        }
      ]
    }
  5. Create an IAM Policy to allow Styra DAS to create and manage S3 buckets and objects. Replace the variables in the following policy template, then add it to a new IAM Policy in your AWS Account. The IAM policy will be referred to as STYRA_S3_ACCESS_POLICY going forward. 
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "s3:CreateBucket",
            "s3:DeleteBucket",
            "s3:GetBucketPublicAccessBlock",
            "s3:GetBucketTagging",
            "s3:GetBucketVersioning",
            "s3:GetEncryptionConfiguration",
            "s3:GetLifecycleConfiguration",
            "s3:ListBucket",
            "s3:PutBucketPublicAccessBlock",
            "s3:PutBucketTagging",
            "s3:PutBucketVersioning",
            "s3:PutEncryptionConfiguration",
            "s3:PutLifecycleConfiguration"
          ],
          "Resource": [
            "arn:aws:s3:::<STYRA_RESOURCE_PREFIX>*"
          ]
        },
        {
          "Effect": "Allow",
          "Action": [
            "s3:AbortMultipartUpload",
            "s3:DeleteObject",
            "s3:GetObject",
            "s3:PutObject"
          ],
          "Resource": [
            "arn:aws:s3:::<STYRA_RESOURCE_PREFIX>*/*"
          ]
        }
      ]
    }
  6. Create an IAM Policy to allow Styra DAS the ability to configure DynamoDB scaling. This policy will also allow the Styra IAM User or Role to pass the DynamoDBAutoscaleRole Role to the DynamoDB service itself (see Granting a user permissions to pass a role to an AWS service for more information on iam:PassRole). Replace the variables in the following policy template, then add them to a new IAM Policy in your AWS Account. The IAM policy will be referred to as STYRA_DYNAMODB_SCALING_POLICY going forward. 
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "application-autoscaling:DescribeScalableTargets",
            "application-autoscaling:DescribeScalingPolicies"
          ],
          "Resource": [
            "arn:aws:application-autoscaling:<AWS_REGION>:<AWS_ACCOUNT_ID>:scalable-target/*"
          ],
          "Condition": {
            "StringEquals": {
              "application-autoscaling:service-namespace": "dynamodb"
            }
          }
        },
        {
          "Effect": "Allow",
          "Action": [
            "application-autoscaling:PutScalingPolicy",
            "application-autoscaling:RegisterScalableTarget"
          ],
          "Resource": [
            "arn:aws:application-autoscaling:<AWS_REGION>:<AWS_ACCOUNT_ID>:scalable-target/table/<STYRA_RESOURCE_PREFIX>*"
          ]
        },
        {
          "Effect": "Allow",
          "Action": [
            "iam:PassRole"
          ],
          "Resource": [
            "arn:aws:iam::<AWS_ACCOUNT_ID>:role/service-role/DynamoDBAutoscaleRole"
          ]
        }
      ]
    }

AWS IAM User​

Styra DAS can be configured to use a single IAM User to access and configure both Amazon DynamoDB and Amazon S3. The following steps cover how to properly configure the IAM User for use with Styra DAS.

  1. Create a new IAM User.
  2. Attach the STYRA_DYNAMODB_ACCESS_POLICY, STYRA_S3_ACCESS_POLICY, and STYRA_DYNAMODB_SCALING_POLICY IAM policies to the IAM User
  3. Create an access key for the IAM User and save the access key ID and secret access key ID for Configuration and Installation.

AWS IAM Role​

Styra DAS can be configured to use an IAM Role to assume the permissions necessary to manage and work with DynamoDB and S3. The following steps cover how to properly configure the IAM Role for use with Styra DAS.

  1. Create an AWS IAM Role. See Creating IAM Roles for additional information. Leave the trust relationship policy empty, as it will be configured in the following steps. The IAM Role will be referred to as STYRA_IAM_ROLE.
  2. Locate the OpenID OIDC Provider URL for your EKS cluster. This will be needed to construct the trust relationship policy of the IAM Role:
    1. Navigate to Amazon Elastic Kubernetes Service in the AWS Web Console.
    2. Select “Clusters” in the navigation bar.
    3. Click “Details” of the EKS cluster where Styra DAS will be deployed.
    4. Find the full provider URL in Overview > Details > OpenID > Connect provider URL.
    5. Remove the https:// prefix from the URL.
    6. Use the resultant value to replace the three instances of the OIDC_PROVIDER_URL in the following policy template.
  3. Determine a Kubernetes ServiceAccount name for use with Styra DAS. We recommend you use the name styra-das, as that is the default value in the Helm chart’s values.yaml file. If you use another value, you will have to update the top-level serviceAccount field to match during Configuration and Installation. Use the ServiceAccount name to replace the STYRA_DAS_SERVICE_ACCOUNT field in the policy file below.
  4. Replace all templated values in the following policy template and save the result as a local policy file. 
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/<OIDC_PROVIDER_URL>"
          },
          "Action": "sts:AssumeRoleWithWebIdentity",
          "Condition": {
            "StringEquals": {
              "<OIDC_PROVIDER_URL>:aud": "sts.amazonaws.com",
              "<OIDC_PROVIDER_URL>:sub": "system:serviceaccount:<STYRA_DAS_NAMESPACE>:<STYRA_DAS_SERVICE_ACCOUNT_NAME>"
            }
          }
        }
      ]
    }
  5. Attach the completed policy to the STYRA_IAM_ROLE.

Ingress​

Self-Hosted Styra DAS requires both a cloud-provider provisioned LoadBalancer and Kubernetes-side configuration to make Styra DAS available to incoming network requests. This section describes AWS-specific considerations before deploying Styra DAS.

note

The following options can also be configured through Configuration and Installation.

The primary areas of consideration when deciding on an approach to network ingress are:

  • AWS Elastic Load Balancer Type
  • Transport Layer Security (TLS) Configuration
  • DNS Configuration

AWS Load Balancer Controller​

The AWS Load Balancer Controller is an optional add-on to Kubernetes that unlocks several configuration options when running Kubernetes in AWS. In addition to several other configuration options, the AWS Load Balancer Controller supports the following functionality:

  • Use Application Load Balancers
  • Auto-configure TLS termination at the Load Balancer using Amazon Certificate Manager
  • Auto-configure Amazon Route53 DNS record creation
note

While it is possible to install Styra DAS without AWS Load Balancer Controller, it is recommended to use the AWS Load Balancer Controller to auto-provision networking infrastructure. See Installing the AWS Load Balancer Controller add-on for additional information.

AWS Elastic Load Balancer Types​

Amazon’s Elastic Load Balancing offers several types of load balancers. For a comparison of the features and configuration options of the different load balancer types, see Elastic Load Balancer features.

The default AWS cloud provider load balancer controller is capable of creating a limited set of Load Balancer types, but is only receiving critical security updates. Instead, Styra recommends using the AWS Load Balancer Controller, which is both actively maintained, and capable of creating any type of Load Balancer other than “Classic” Elastic Load Balancers.

When using the AWS Load Balancer Controller, the behavior of the generated Load Balancer can be configured using annotations on a Kubernetes Service or Ingress. By default, the Styra DAS Helm chart creates a Service and can be configured by adding any documented Service annotations to gateway.service.annotations in your values.yaml during Configuration and Installation. The following example demonstrates using Service annotations to configure an internet-facing, instance mode Network Load Balancer:

gateway:
  service:
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
      service.beta.kubernetes.io/aws-load-balancer-type: "external"
      service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "instance"

TLS Configuration​

TLS Configuration refers to how you set up SSL termination for incoming network requests. There are two primary configurations recommended when running Styra DAS in AWS:

  • Terminate SSL connections at the Load Balancer using Amazon Certificate Manager managed certificates (requires AWS Load Balancer Controller)
  • Terminate SSL connections at the gateway Kubernetes service (requires local certificate files)

If you can use AWS Load Balancer Controller and Amazon Certificate Manager, we recommend the first approach, which supports using a remote Helm repository during installation, rather than having to download the Styra DAS Helm chart locally. To handle SSL termination at the Load Balancer using Amazon Certificate Manager, ensure you have a valid certificate for the domain. See Issuing and managing certificates for additional information. Then, during Configuration and Installation:

  1. Set gateway.tls.enabled to false. With the Load Balancer handling TLS, the gateway service does not require managed certificates.
  2. Add an service.beta.kubernetes.io/aws-load-balancer-ssl-cert annotation to gateway.annotations.

The resultant gateway section in your values.yaml should resemble the following:

gateway:
  tls:
    enabled: false
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:<REGION>:xxxxx:certificate/xxxxx

If you choose to terminate the TLS connection at the gateway Service instead, please refer to “Installing from Local System” instead of “Installing from Helm Repository” in Configuration and Installation. “Installing from Local System” covers how to provide gateway certificates to the Kubernetes Service during the Helm installation process.

DNS Configuration​

DNS Configuration describes how you create a fully qualified domain name for your installation of Styra DAS. When running Styra DAS in AWS, there are two primary options for DNS configuration options:

  • Automatic DNS Configuration using external-DNS (requires AWS Load Balancer Controller and external-DNS)
  • Manually configure a DNS record

Automatic DNS Configuration​

Ensure that the AWS Load Balancer Controller and external-DNS are installed on the target cluster. There are several ways to install External DNS on to a Kubernetes cluster, though the easiest is to follow instructions here. Installation will be handled using a Kubernetes resource manifest. Installation also requires the creation of several AWS resources, mostly IAM policies and roles. The manifest includes a section where you can configure the URLs for External DNS to pick up on, as well as what resources (services or ingress) it should look at for these annotations. For External DNS to be able to pick up your Styra DAS domain, ensure that External DNS is configured to look at services, and that your domain filter won't exclude your domain. After installation, you can add an external-dns.alpha.kubernetes.io/hostname annotation to the gateway service in your values.yaml. This can be done by adding it to gateway.service.annotations, similar to the following:

gateway:
  tls:
    enabled: false
  service:
    annotations:
      external-dns.alpha.kubernetes.io/hostname: my-app.my-domain.com

Manual Configuration​

The following steps are used to configure manual configuration:

  1. After completing the steps in Configuration and Installation, look for the “External IP” of the provisioned Load Balancer using the following command: 
    kubectl get service gateway -n styra-das
  2. Use the “External IP” value as the target IP for a DNS record with your DNS provider.