Run Curity Identity Server on AWS (CloudFormation Template)
In this tutorial we will use CloudFormation to install a cluster in AWS. We will also go through all the options the CloudFormation template has to utilize other AWS services. You can find the template in GitHub
The CloudFormation template will create several AWS resources, namely:
- An EC2 instance for the admin node
- A launch configuration for the runtime node(s)
- An Application Load Balancer (ALB)
- IAM roles and profiles which will be attached to the nodes
- Security groups for both node types and the ALB
- An S3 bucket where the cluster configuration will be stored
- Log groups, if logging into CloudWatch is enabled
- Scaling policies and alarms, used for autoscaling
We will refer to these resources as we explain the parameters the template expects later in this tutorial.
The CloudFormation template has three parameters that require some preparation.
KeyName is a reference to the SSH key that will be installed in both node types, so that you have SSH access. To create one, navigate under EC2 -> Key Pairs and create a key pair.
CertificateArn is the
arn of a certificate that is verified by AWS, you can import or generate one in the Certificate Manager in the AWS Console.
EFSDNS is the DNS name of the EFS storage which can be used to store template and message overrides, as well as plugins that you want installed in your cluster.
Import the template to create a CloudFormation Stack¶
In the AWS console, navigate under CloudFormation and create a new stack. Upload the template file and click next.
Specify Stack Details step, you are required to enter a stack name and select/fill the parameters available for the template configuration.
Understanding the parameters¶
The parameters are divided in five sections:
1. Node Configuration¶
In this section you can select what EC2 instance type the nodes will use, as well as select how many runtime nodes will be created in your cluster and select the SSH key which will be installed in the instances. You can select a different instance type for admin and runtime nodes with the parameters
RuntimeInstanceType respectively. Since the clustering mode used here is Standalone Admin Setup, the
AdminInstanceType can be a less powerful instance than the
RuntimeInstanceType. The parameters
RuntimeMaxNodeCount are relevant to the runtime nodes (auto-scaling group) and define the minimum and maximum size of the
AutoScalingGroup respectively. Finally the
KeyName is a reference of the SSH key that you should have already created during preparation (it should appear in the dropdown).
Here you can select which Virtual Private Cloud will be used (
VpcId), as well as the
Subnets that the instances will live on. You must select at least two subnets.
Also there are two configurable IP ranges, the
LoadBalancerIpRange. The former is the range of IPs that are allowed to access the Curity admin UI and have SSH access to the instances. The latter is the IP range that will be allowed to access the Curity runtime services through the ALB.
3. AWS Services¶
In the AWS Services section you can (optionally) configure a
CertificateArn. If that is set, the ALB will listen on HTTPS traffic (port 443), if not, on HTTP (port 80). Also, if the certificate is configured, the admin UI will be reachable through the ALB as well on port 6749, but only from the
TrustedIpRange configured previously.
EFSDNS is also an optional parameter of the EFS Storage that contains template or message overrides or plugins. You can find instructions on how to use that in the readme of the Github repository.
CloudWatchNamespace is configured, the metrics of the Curity Identity Server will be pushed to CloudWatch.
MetricsScrapeInterval is only relevant when
CloudWatchNamespace is configured and it is the interval of the metrics scraping.
EnableCloudWatchLogs is enabled, all the relevant log files of the Curity Identity Server will be monitored and pushed to CloudWatch logs.
4. Auto Scaling¶
The Auto Scaling in this setup is done by utilizing metrics of the ALB. In this section you set the thresholds which, when exceeded, instruct the Auto Scaling group to scale up or down.
MaxRequestsPerRuntimeNode is the maximum threshold of concurrent requests (connections) per runtime node.
MinRequestsPerRuntimeNode is the minimum threshold of concurrent requests (connections) per runtime node. Exceeding these limits will scale up or down the cluster.
5. Curity Configuration¶
In the final section of the parameters you can find some configuration options that are directly related with the Curity Identity Server. First, we find the
AdminUserPassword, which is the admin user's password, used to login to the admin UI. You can also optionally configure a
ConfigEncryptionKey (read more about this here) Lastly, you can configure the
RuntimePort which are the service-role and port that the runtime nodes are expected to use.
Configure the parameters and launch the stack¶
Now that we have explained the parameters and what they are used for, let's continue by configuring the required ones and some extra which will allow us to explore most of the features of this CloudFormation template.
- Select the
KeyNamethat appears in the dropdown, which you have created during the preparation
- Select one (if there are many options in your region)
- Select at least two of the available
- Configure a
CloudWatchNamespace, e.g. curity-demo
- Enable the
- Set an
Click Next and go through the
Stack Options step, this is a standard step when creating a CloudFormation stack, no changes are necessary. Click Next again which should get you to the
Review step. Before clicking on
Create Stack, you will have to acknowledge that AWS CloudFormation creates IAM resources. When this is done, you will be able to create your stack. After a couple of minutes, you should see that all the resources and the stack status is
CREATE_COMPLETE. In the stack page, you can navigate to the
Outputs tab where you will find the URL for the Curity admin UI.
You learned how to create a cluster of the Curity Identity Server by using the CloudFormation template. The stack created included one admin node and two runtime nodes.
You specified an initial password for the admin service and enabled the admin UI on the admin node.
The CloudFormation template took care of the cluster configuration and created a cluster encryption key used for securing the communication between the admin and runtime nodes.
Let’s Stay in Touch!
Get the latest on identity management, API Security and authentication straight to your inbox.