IronWorker Security

Years of work and many layers are involved in ensuring cloud resources are secure. Iron.io inherits these industrial-strength security measures through the infrastructures we operate on. These measures include physical, network, data continuity, service access and service-specific protections, among others. Please refer to the AWS Security Whitepaper for a detailed description of this extensive list.

Iron.io takes further measures to isolate and protect processes at the IronWorker platform level, just as we isolate and protect instances at the infrastructure level. These steps include access restrictions, process isolation, resource monitoring/management, service restrictions, and more.

Security Measures

OAuth2 Authorization

Iron’s API uses OAuth 2, an industry-standard authentication scheme, to securely authenticate API requests. This scheme relies on SSL for security, instead of requiring your application to do cryptographic signing directly. This makes the API easy to use without compromising security.

HTTPS Encryption

The IronWorker API is the standard method of interacting with workers and projects. HTTPS encryption is the default access method for the API and the recommended approach for all access requests. All the client libraries provided by Iron.io use HTTPS encryption by default. This renders most common packet-interception attacks useless.

Process Isolation

IronWorker makes use of OS-level sandboxing to keep processes isolated from system influences and other processes in the system. Each IronWorker process runs in a virtualized container that appears to processes as a unique, minimal Ubuntu installation. Runtime limits are placed on the amount of RAM and disk each worker process may consume. Workers that exceed the memory limit will error out and exit. CPU allocation is balanced across IronWorker processes, but may burst to higher CPU allocation depending IronWorker system load.

Resource Management

IronWorker uses process-level runtime monitoring/management to ensure that workers receive a standard set of compute resources. Workers may utilize more resources depending on system load (which could introduce slight performance variations across workers) but never less than the standard level.

SMTP and Other Service Restrictions

IronWorker, by design, does not provide SMTP host services. Workers must use third-party services such as GMail, SendGrid, Amazon SES, or other service providers. Users must also adhere to Iron.io’s Use Policy.

Accessing resources behind a firewall

Customers using the public cluster can whitelist the Amazon AWS IP Range for the region where their services are located. IronWorker users would use the IPs for us-east-1. IronMQ users would use the region where their queues are located; which is available in The Dashboard.

Enterprise customers using a dedicated cluster should contact Iron.io Technical Support to cordinate a configuration for firewall access.

Accessing resources on AWS

Customers using the public cluster can create inbound security rules using the Amazon AWS IP Range for the region where their services are located. IronWorker users would use the IPs for us-east-1. IronMQ users would use the region where their queues are located; which is available in The Dashboard. Or they may create an inbound security rule to allow all traffic using 0.0.0.0/0.

Enterprise customers using a dedicated cluster should contact Iron.io Technical Support to cordinate a VPC peering connection, or a restricted list of IPs to whitelist.

Security Guidelines/Best Practices

Environment Variables/Code Separation

Avoid including any sensitive data or credentials within your code. Instead, include them as part of the data payload. This is in keeping with the 12-Factor app tenet regarding Config and its guidance on strict separation of config from code.

Create Worker-Specific Credentials

Make use of worker-specific credentials that only your workers depend on. For example, database users can be set up specifically for one or more workers. Additional auth tokens can be created for API services. Restricting/limiting these credentials to only the services/tables/capabilities workers need will provide an added level of isolation. It also makes changing/rotating credentials easier.

Encrypt Data Payloads

Consider encrypting your sensitive data before including it as part of the payload, and then decrypt it in the worker. This measure requires an attacker compromise both the payload and the worker in order to gain access to the data.

Restrict Logging

Do not log sensitive data. This includes sending information to STDOUT, as STDOUT is included in IronWorker’s logs. If certain ID information is needed then provide an excerpt of the data (e.g xxxx4f689a5 or 32e78f….) that can be used for identification purposes.

Questions/Concerns About Security Issues

We’ve taken measures to ensure the security of your data in our systems, and we’re working hard to educate customers on how to make the most of that security. Our mission is to take the stress out of managing cloud infrastructure, and that includes concerns about security and compromised data.

If you have any questions, please do not hesitate to get in touch with us. We encourage the dialogue and want to do everything we can to ensure the safety of your data. Email support@iron.io to get and we’d be happy to answer questions or provide advice on a case-by-case basis.