Subnets

Interana creates two subnets with the VPC, one public and one private. The public subnet contains the admin and API nodes and uses CIDR 10.0.0.0/24. External inbound traffic is routed to the public subnet. The private subnet contains the config, import, data, and string nodes, and uses CIDR 10.0.1.0/24. A Network Access Control List (ACL) controls the communication between the two subnets.

Security groups

Interana creates a default security group to control ingress to and egress from the cluster, and applies to the API nodes on the public subnet. Additionally, Interana creates a private security group that controls access to nodes on the private subnet, as well as an admin security group that controls access to the admin node.

AWS Identity Access Management

The Interana must have AWS credentials in order to provision, deploy, and manage an Interana cluster. This requires that you create an Interana user account with the necessary permissions restricted to your target AWS account (see Policies below). Interana stores these credentials securely and accesses them to deploy the cluster and perform cluster upgrades and maintenance. 

Key storage

Interana stores AWS credentials in an encrypted database, and utilizes a key vault solution to encrypt and restrict access to the keys exclusively to Interana. All AWS API requests are made over SSL. Interana supports rotating AWS credentials at the customer's request.

Access control

Security groups on the cluster restrict access to approved Interana IP addresses. Additionally, each Interana Customer Support Engineer that accesses your system must have a unique login with key access. Interana uses a third-party cloud LDAP service that syncs with Interana internal LDAP servers for account management. Each Customer Support Engineer must have an unique SSH key, and every login attempt is validated. This ensures that only an authorized account and SSH key can access your account. Access is granted based on group membership that is approved by you.

Interana collects logs that record SSH access to the cluster for auditing purposes. Access logs are uploaded to a host in the Interana AWS environment for analysis. Customers can request a report of access to their cluster.

Monitoring a cluster

Interana monitors the health of Interana cluster nodes and application processes. Each node in the cluster is configured to send metrics to a web API on a secure server. An API key is used to authenticate with the server that is authorized for reporting telemetry only (no read access, no account configuration access, no access to data stored on cluster). 

The following metrics are collected:

• Node availability
• Node reboot
• CPU
• Thread count per process
• Memory - RSS, VM, Malloc, MMAP
• File descriptors
• TCP ports
• Disk space (root, data, log, backup volumes)
• Disk I/O and throughput
• Application disk space (import, config/database, cache)
• Crons
• Bytes sent and received

Within the cluster, the following ports are used for collecting and transmitting cluster metrics:

Automating cluster maintenance 

Interana manages the state of the cluster with an orchestration and configuration management tool. Processes run on each node and communicate to the server in the Interana AWS environment on ports 4505 and 4506.

Upgrading a cluster

Software upgrades are similar to the initial Interana software installation. Interana manages upgrades, connecting to the admin node and using it as a proxy to run upgrades on the other nodes in the cluster. 

Ingesting data

The Interana import nodes manage a pipeline for ingesting data into the cluster. Import nodes are configured to pull files from a designated S3 bucket. After the files are downloaded, they are processed and deleted.

Access to the source data bucket is configured through a bucket policy that is set by you. Read-only access must be granted for the Interana IAM user. The bucket policy should allow the following actions on the data source bucket and resources within the bucket:

• s3:GetBucketLocation
• s3:ListBucket
• s3:GetObject
• s3:RestoreObject

User authentication

This section provides and overview of the methods Interana supports for authenticating users through the Interana web user interface (UI). For more information, see the article on Using other forms of authentication.

Email notifications

The Interana application sends emails for account creation and management (if user/password authentication is enabled), as well as for scheduled dashboard reports. The service used to send emails is configurable, with the basic requirement of an SMTP interface (host, port, username, and password). Interana supports the following email services:

• Sendgrid—Interana default email service. Emails are sent from the interana.com domain.

• Amazon Simple Email Service (SES)—Amazon SES can be configured to send Interana emails from the interana.com domain. If Amazon SES is configured, the DomainKeys Identified Mail (DKIM) signing of emails is enabled.

• Customer mail server—A customer-owned mail server may be used to send Interana emails. For this, the customer needs to provide SMTP configuration information. Emails are then sent from the customer domain.