Skip to main content

Riscosity AWS Setup Prerequisites Guide

Updated

Overview

Riscosity setup involves creating a new stack in AWS using AWS Cloudformation Template. The installation follows a two-step approach where the first step is to install an installer web application and the second step involves using the new installer to spin up the stack and related infrastructure in AWS. 

 The initial setup and verification process is coordinated over live screen sharing and requires a technical resource familiar with AWS and customer infrastructure setup.

 The validation process involves configuring the installed software with info specific to the customer such as adding relevant users, product code repositories, configuring proxy for managing traffic to specific domains etc. This step can be done separately from initial setup and does not require AWS access or expertise.

Prerequisites and Preparation for deployment

Riscosity setup requires the following information ready before deployment of the product stack.

Please go through the following steps carefully and complete each before proceeding with the product deployment.

The only information you’ll need to share with us before the deployment session is the AWS Account ID and region. You don’t need to share the access keys or any other sensitive info. Riscosity will not have access to any credentials you use, and no sensitive information will be sent or shared with us at any stage.

  1. Customer AWS Account ID & region

This is where the Riscosity product stack is to be installed. Provide us this info and the  product AMIs will be shared to this account prior to installation.

  1. AWS Console login access

Customer AWS console login which is used for deployment session should have privileges to perform various operations such as create user and associated security credentials, spin up new stack and relevant resources based on Cloudformation template. 

  1. Create AWS user with required privileges

An existing or new IAM user with either admin privileges or the list of privileges specified in the Appendix below.

 It may be practical to create these as customer-managed policies and then assign them as the permission policies of two or more user groups. Then, it is recommended you add the Riscosity product user as a member of these groups.

These policies will ultimately be used when you are logged in to the Riscosity Installer and / or the Riscosity web application. These permissions will be used to deploy and update the Riscosity product via access key credentials.

  1. Steps to create an AWS IAM user:
  1. Go to AWS Console IAM > Access management - Users and click on Create user.
  2. Enter a username. Eg: riscosity-user
  3. Click Next to proceed with defaults to the final page and click Create user.
  1. Steps to create policies (one at a time): 
  1. Go to AWS Console - IAM > Access management - Policies and click on Create policy.
  2. Select the option JSON(on top-right - see screenshot). This should bring up the Policy editor where we can manually paste the contents of the first policy listed in the Appendix. 
  3. Any omissions or errors will be flagged by the editor. Missing braces, quotes etc. are common sources of syntax error. Correct any errors and proceed to Next
  4. Enter a policy name matching the policy contents (Eg: riscosity-policy-ec2, riscosity-policy-s3 etc.) and click Create policy.
  5. Repeat the above steps for each policy listed in Appendix to finish creating all policies listed except the one for iam permissions.

  1. Create user groups and attach policies required.
  1. Go to AWS Console - IAM > User groups and click on Create group.
  2. Enter a group name. eg: riscosity-usergroup-A
  3. Select the IAM user created from under the “Add users to the group” option.
  4. Select the first 8 policies created(acm to rds related policies) from under “Attach permissions policies” option on the same page.
  5. Proceed to click Create group to finish.
  6. Repeat the above process to create a second user group riscosity-usergroup-B and attach the IAM user and rest of the policies except the one with iam permissions.

IV. Attach the policy corresponding to iam permissions to the user directly as follows.

  1. Select the IAM user, expand the Add permissions button dropdown under the Permissions tab corresponding to the user.
  2. Click on Create inline policy from the Add permissions button.
  3. Select JSON editor and proceed to create the policy for iam by entering the policy details for iam from Appendix and giving the right name.
  4. Remember to substitute the right account id and username in the user arn while creating the inline policy.  "arn:aws:iam::<aws_account_id>:user/<username>".

  1. AWS Access key for infra setup and reading DNS Logs

Permanent(long-term) AWS ACCESS_KEY & SECRET_ACCESS_KEY for the AWS user created in the previous step. These credentials will be used to dynamically manage the stack and related resources such as proxy components.

Note: Temporary credentials with session token cannot be used for deployment. For example, temporary credentials generated for federated users authenticated via an external identity provider(IdP) such as OKTA cannot be used.

Steps to create AWS Key/secret:

  1. Go to AWS Console EC2 > IAM users > Select the user with the required privileges
  2. Go to Security Credentials tab > Click Access keys - Create Access key option.
  3. Select option ‘Other’ from “Access key best practices & alternatives” step and proceed to create the key.
  4. Download the Access/Secret key pair and save it securely. 

Note: This cannot be retrieved once lost.

Configuring the Network Traffic Scanner(NTS) component requires AWS account ID, region, ACCESS_KEY & SECRET to read S3 bucket that stores DNS traffic logs of VPCs in which products are deployed. This can be different from the primary AWS account ID/user mentioned above. NTS also allows registering multiple aws account-keys for reading DNS logs for applications deployed under different accounts/vpcs.

Note: For PoC deployments, no separate account/user/keys are required and the primary user key itself will be used for configuring NTS.

  1. Create SSH key pair

An SSH key pair for accessing the stack via the backend. You may reuse an existing one.

Steps to create SSH key pair:

  1. Go to AWS Console > Select the correct region.
  2. Go to EC2 > Network & Security - Key Pairs > Create Key pair
  3. Enter a Name. eg: riscosity-key.
  4. Select Key pair type as ed25519.
  5. Leave all other options as defaults and click Create key pair.

The private key will be automatically downloaded to your computer. 

Note: Sometimes the computer might save the downloaded key under a different name. Look for the latest under downloads in such cases.

Keep the private key under a secure location or a password vault. This cannot be retrieved once lost.

  1. Create VPCs and Subnets

An existing/new AWS VPC where the Riscosity installer and stack will be deployed. This needs to be accessible from outside so that the installer/portal can be accessed after the setup.

The new VPC’s CIDR Block should be unique and shouldn’t overlap with any of the existing VPCs’ CIDRs.  See FAQ for more information.

Add 2 public subnets (with attached Internet Gateway) in the designated VPC which are under different availability zones.

Add 1 private subnet (with NAT gw) for each AZ available for that specific region.

If you are on us-east-1 then make sure to cover all availability zones (6 for us-east-1, 3 or 4 for any other region depending up on the availability zones under each region)

Ref: https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-availability-zones.html

Steps to create VPC for the main stack:

  1. Go to VPCs and click Create VPC
  2. Select option “VPC and more”
  3. Enter a Name tag under ‘Name tag auto-generation’. Eg: riscosity-stack-vpc
  4. Enter a non-overlapping private IPv4 CIDR block. eg: 10.0.0.0/16
  5. Leave the private/public subnets as 2. See below for explanation.
  6. Select ‘In 1 AZ’ under NAT Gateways
  7. Leave all other options as defaults and click Create VPC. See screenshot below for default options of 

Review the configuration using the Preview section to make sure the subnets are distributed across multiple zones. Use Customize AZs to correctly select the subnet-zone mapping.

Important Note: Since the ability to select the required subnet-availability zone mapping via AWS Console UI is limited, we will have to limit the number of subnets created via UI to 2 or 3 and will have to manually add the subnets corresponding to the rest of the availability zones with the right routing info.

Steps for manually adding subnets for availability zones for which subnets weren’t created:

  • Go to AWS Console > VPC > Subnets and click Create subnet.
  • Select a meaningful subnet name based on the existing subnet names. Eg: riscosity-subnet-public4-us-east-1d, riscosity-subnet-private5-us-east-1e
  • Select the next missing Availability Zone based on existing subnets’ zones.
  • Select a CIDR address block within the VPC’s CIDR range and create.
  • Create VPC-Route tables by selecting the correct VPC and following proper naming conventions.
  • Add the routing for local traffic in case of manually added subnets. 
  • Add NAT gateway for 0.0.0.0/0 to grant external access to new private subnets. 
  • Select the route tables and map the tables to the subnets via Subnet associations > Explicit subnet associations tab from detail page of selected route table.

It may be easier to refer to the routing configuration of existing private/public subnets while doing this.

Notes: 

You need to make sure that VPC Service Quota for those regions aren’t already maxed out. 

You can use private subnet only installation if needed. However, access to the setup needs to be configured via VPN/bastion server or some other mechanism. See Troubleshooting section for more information.

  1. Create VPC for Governance Demo and NTS configuration

A separate new VPC is required for the setup and configuration of the NTS component and the Governance Demo configuration. It is recommended to have public subnets for easy access of the demo app. 

Steps to create VPC:

  1. Go to VPCs and click Create VPC
  2. Select option “VPC and more”
  3. Enter a Name tag under ‘Name tag auto-generation’. Eg: riscosity-govdemo-vpc
  4. Enter a non-overlapping private IPv4 CIDR block. eg: 10.100.0.0/16
  5. Select ‘In 1 AZ’ under NAT Gateways
  6. Leave all other options as defaults and click Create VPC.

Use Preview option to see subnet-zone distribution before vpc creation.

  1. S3 bucket for DNS traffic logging

An S3 bucket for storing DNS query logs for the VPC on which the target applications (Governance Demo in case of PoC) reside. This is used by the NTS component.

Steps to create S3 bucket:

  1. Go to AWS Console > S3 and click Create bucket
  2. Enter a globally unique Bucket name. Eg: riscosity-yourdomain-s3-nts
  3. Use default values for the rest of the options and click Create bucket.

See following section for details on how to use this bucket as the destination for VPC Query logging.

  1. Enable Query for GovDemo VPC

Enable query logging for the VPCs for which the network traffic needs to be captured.

Steps to enable VPC Query Logging:

  1. Go to the AWS Route 53 Dashboard 
  2. Click on Query Logging under the Resolver section, click Configure query logging 
  3. Select ‘S3 bucket’ option under ‘Destination for query logs’
  4. Enter the S3 URI as s3://riscosity-yourdomain-s3-nts where the last part is the name of the bucket we created for traffic logging. Please note that this is NOT the s3 bucket ARN or bucket name.
  5. Click Add VPC button under “VPCs to log queries for”
  6. Select & Add the newly created governance demo vpc from the previous step.

We can create an S3 bucket and enable query logging for all the VPCs we want to configure within the NTS.

  1. SSL Certificate

Import SSL cert for your web app domain (e.g. *.yourdomain.com), to the AWS Certificate Manager so that the stack can be accessed via an easy-to-remember FQDN such as riscosity.yourdomain.com. The imported certificate’s ARN will be used during installation.

In case if a cert is not readily available, we recommend importing the *.riscosity.net  which we will provide to the ACM. 

Steps to import *.riscosity.net to AWS ACM:

  1. Go to AWS Console > Certificate Manager and select the correct region.
  2. Click on Import certificate
  3. Enter the entire contents (including BEGIN/END CERTIFICATE lines) of STAR_riscosity_net.crt file under Certificate body
  4. Enter the entire contents of the STAR.riscosity.net_key.txt file under Certificate private key
  5. Enter the entire contents of the STAR_riscosity_com.ca-bundle file under Certificate chain option.
  6. Click Import certificate to proceed.

  1. Access to add DNS entry for Riscosity portal & installer

For ease of access, we recommend adding a CNAME record to the client domain’s DNS zone file pointing to the DNS name of the load balancer corresponding to the Riscosity web portal. This is to be done AFTER the installation once the URL to the portal’s load balancer is available.

The exact steps for adding a CNAME record depends on the DNS provider (Route53, Cloudflare, Godaddy etc.). If we decide to go with Riscosity’s certificate, the Riscosity team can take care of adding the DNS records.

In addition to the web portal, the same can be done for setting up DNS for the Riscosity Governance demo. Eg: riscosity-govdemo.yourdomain.com

  1. Code Repositories

Identify a set of applications/products and corresponding code repositories(private or public) which can be scanned and ensure they are accessible from the VPC where the product is deployed. These are required for Riscosity product validation. Any code repo can be used during installation verification. If no repos are readily available, the Riscosity team can help configure it for you.

  1. IPs to whitelist

IP CIDR range with HTTPS access to be whitelisted for accessing the Riscosity Installer/portal. Additional IP ranges can also be whitelisted post-deployment. 

  1. Setup duration timeline

Two one and a half hour sessions with technical staff for initial AWS product deployment and verification.

A 45 minute session for post-deployment configuration, validation and demo of the product.

  1. Technical Resources required

An authorized technical staff who is familiar with AWS and current AWS infra setup of the customer. This representative will work with the Riscosity team to complete the product setup via AWS Console.

The AWS Cloudformation Template(CFT), AMI IDs, billing token, various API keys etc. required for the install and associated configuration parameters will be shared via email in advance or during the installation session.

Summary

The pre-deployment prerequisites setup involves setting up the base aws resources and making sure that the right access and information is available prior to the actual product deployment and validation.

Please feel free to reach out to the Riscosity team in case of any questions regarding the preparations involved. We would be happy to have a prep call prior to the install for charting out the way forward with the installation.

Appendix / Resources:

FAQ

  1. What are the IAM permissions required for setting up the product?

Refer to PermissionsRequiredToInstallRiscosityProduct.txt doc for the latest list of permissions and policies to be added.

  1. Can I use private subnets only for the product installation?

Customers can choose the installer option RiscosityInstallerAlbScheme as ‘internal’ and select private VPC subnets without an associated Internet Gateway. However, customers will need to make alternate arrangements such as VPN or bastion hosts to make the installer and web portal accessible for further governance. The private subnets need attached NAT Gateways for accessing outside resources.

Use the standard VPC creation(with public subnets) steps outlined above and then specify the private subnet ids during the actual deployment.

  1. How do I select the correct CIDR for deploying Proxy?

The new CIDR specified should not overlap with any of the existing VPCs IPV4 Addr range or with the range of any of the VPCs with which they are peered with.

You can see the current range from AWS Console VPC listing and use an online tool to see if the specified VPCs’ address space collide. Typically, addresses such as 10.100.0.0/16 is a good starting point. If it is already being used, we can try 10.101.0.0/16 so on and so forth.

Troubleshooting guide

  1. Unable to create a VPC.

You need to make sure that VPC Service Quota for those regions aren’t already maxed out. Request for increasing VPC quota from here: Service Quotas > AWS services > Amazon Virtual Private Cloud (Amazon VPC) > VPCs per Region. 

Click on Request increase at account level and submit a request. This should get approved within a few min. The same is applicable for Elastic IP quotas as well.

  1. Unable to attach policy to aws user.

There is a limit on the max number of policies that can be attached to a user inline. Create user groups and attach policies to the groups and attach the group to the user instead of attaching policies inline.

  1. Error while adding IAM policy.

Make sure the exact syntax is preserved while copy-pasting policy rules to AWS Console.

Glossary

Installer: Web application deployed using AWS CFT which is used to deploy the Riscosity stack.

Portal: Web portal for configuring and managing the Riscosity product.

NTS: Riscosity Network Traffic Scanner

Proxy: Riscosity's proxy component used for data governance.

Gov demo: A demo web application deployed to illustrate real-time traffic governance capabilities.

Contact details

Slack: We will create a slack group with you prior to installation, please use this as the primary communication channel outside of our scheduled calls.

Email: support@riscosity.com

Related articles

Powered by Zendesk