Platform Update - Cloud Service Credentials, Payload Usage Visibility

Today’s platform update provides a big security and usability improvement for Losant developers who connect their IoT solutions to third-party cloud services, in addition to new features for organization admins and application developers.

Secure Cloud Service Credentials

A core feature of Losant’s application enablement platform is its ability to easily connect with the managed services of Amazon Web Services, Microsoft Azure, and Google Cloud Platform. In most cases, usage of those services requires authentication, and the values that make up the auth request are considered highly sensitive. While application configuration is encrypted at rest and in transit, sensitive credentials are still returned in requests and are visible onscreen to anybody with application access — which could be a violation of corporate IT policy, not to mention a poor security practice.

That’s where Service Credentials come in: They’re a more secure and user-friendly way to store authentication keys that connect your IoT applications with other elements of your company’s cloud infrastructure. And most importantly, the sensitive portions of these credentials are never returned to the user after creation, greatly reducing the risk of unauthorized access to your data and processes.

Using Service Credentials

Service Credentials are easy to configure: First, create an auth credential within your cloud provider account that allows service access from the Losant application. Then, within Losant, create a new credential for that cloud provider, give it a name, and copy/paste the values from the cloud provider into the Losant Service Credential.

Once you save the credential, the sensitive portions are encrypted a second time in Losant’s database, where they are used to authenticate real-time integrations (like Google Pub/Sub), workflow node executions (like the Azure: Function Node), and daily application archiving (such as backups to Amazon S3). Credentials are referenced by name when configuring those resources – in lieu of entering the sensitive keys inline per-resource – and the authentication data is retrieved at runtime within Losant’s secure, private cloud environment.

Benefits of Service Credentials

Above all else, Service Credentials is a security feature, and we recommend our users migrate their IoT applications to use this new authentication method to take advantage of its many benefits:

• As stated before, sensitive portions of a Service Credential are never visible after creation, which helps prevent accidental leaking of the credential to unauthorized individuals. Even if you utilize application globals to store credentials currently, the layer of obscurity offered by referencing them through string templates is thin, as any user with application access can see those values.
• Similarly, Service Credentials are never included in application export bundles or workflow exports, which some users share with external developers or commit to version control repositories like Git. Even if using a private repo, it is bad practice to store sensitive authentication data in those systems, and sensitive keys defined inline per resource or in global values will end up committed along with other configuration data.
• Service Credentials can be edited after creation, so once it’s time to rotate auth keys in your cloud provider, it’s a single update to the credential on the Losant end, and every place it is utilized automatically starts using the new authentication keys.

What’s Next for Service Credentials

Supporting all of Losant’s integrations with the big three cloud providers is just the beginning; eventually, Service Credentials will support API tokens for HTTP Nodes, private keys for FTP Nodes, usernames and passwords for Redis Nodes, and more.

Improved Payload Usage Visibility

Today’s release also provides some additional insights into an organization’s payload consumption over time. Just as we exposed stats about notebook minute consumption in our last release, we’re now doing the same for tracking billable payloads at the organization level.

The interface allows for comparing the current billing period to either of the previous two periods, including cumulative payload counts, per-day and per-hour breakdowns, and trend lines based on current consumption. This helps users diagnose runaway payload usage and modify application behavior before overage fees apply.

Expect continued improvements to this portion of our platform as we bring these same insights to users’ sandboxes, and also more granularly at the application level.

Other Updates

As always, this release comes with several minor features and improvements, including:

• We’ve updated our “Add Dashboard Block” interface to include a search filter and sorting by various methods. Even internally, we’ve found it difficult to find a particular block type as our roster has grown over the years, and this change should make building dashboards even easier.
• The Gateway Edge Agent can now connect as a client to third-party MQTT brokers, allowing for publishing messages and subscribing to topics through the MQTT Output Node and MQTT Trigger respectively. Broker connections and topic subscriptions are defined in the agent’s configuration file.
• We’ve added a new Azure: Table Storage Node for interacting with Microsoft Azure’s structured, non-relational datastore service. The node allows for all the basic table operations: querying, inserting, updating, and deleting documents.
• Resources in application export bundles now have more stable placeholder IDs, which makes for cleaner diffs when committing your application revisions to Git repositories or other version control systems.

What’s Next?

With every new release, we listen to your feedback. By combining your suggestions with our roadmap, we can continue to improve the platform while maintaining its ease of use. Let us know what you think in the Losant Forums.