Red Hat® Ansible® Automation Platform is a foundation for building and operating automation at scale. Simple to adopt, use, and understand, Red Hat Ansible Automation Platform provides the tools needed to rapidly implement enterprise-wide automation, no matter where you are in your automation journey.
The Red Hat Ansible Automation Platform now includes Automation Analytics, a powerful service built on the Red Hat Cloud Platform.
Customers naturally want to ensure how their data is handled by Automation Analytics. This document describes the practices used by Red Hat in handling customer data for automation analytics.
Can I access Automation Analytics as an on-premise tool so that we do not have to send system data out of our network?
Automation Analytics is an online service provided within the Ansible Automation Platform by Red Hat. There is no on-premise version of the service planned at this time.
What data is collected by Automation Analytics?
Much like Red Hat Insights, Automation Analytics is built to only collect the minimum amount of data needed.
Automation Analytics collects certain classes of data from Ansible Tower:
- Counts of automation resources (templates, inventories, projects, credentials, etc)
- Topology and status of the Tower environment and hosts
- Job execution details (start time, finish time, success), and individual task success and modules used
Importantly, no credential secrets, personal data, automation variables, or task output is gathered.
For a more detailed description, please see the documentation.
Can you limit what data is sent to Automation Analytics?
Content is not currently configurable. For more information on what is sent and how to view it, please see "How can you view and control what data is collected by Automation Analytics?".
How can you view and control what data is collected by Automation Analytics?
The customer controls whether their Tower data is sent to Automation Analytics or not. No data is sent to Red Hat unless an administrator explicitly opts in to data collection. The administrator can perform a sample collection and inspect the data if they so desire.
To review the data that would be sent, the administrator can run `awx-manage gather_analytics', and examine the file created.
What is the impact of disabling data collection for Automation Analytics?
You can not take advantage of Automation Analytics features to see across your automation estate if data collection is not enabled.
Is the type of data collected static or dynamic?
The specification for what data is collected is defined in Ansible Tower and can change with a future Ansible Tower update.
How is my analytics data transmitted and stored?
Data is encrypted throughout the process - from collection, to transmission, to storage on Red Hat infrastructure.
How long will Red Hat retain the data collected?
By default, the service collects and uploads the data four times a day. Hence, the collected data will normally be kept for up to 24 hours for processing into computed analytics data. Data uploaded by previous runs will be discarded when the same client uploads new data as part of the daily run.
As we are building the product to show historical automation data, computed analytics data is currently stored for up to a year.
Security of hosted services
Infrastructure and Architecture
Security of customer data in Red Hat is a priority and every effort is made to ensure that information is not unnecessarily persisted and that it is secured using industry standard best practices.
All customer data provided is stored within a secure data center with controlled access.
All volumes containing customer data at rest are encrypted with AES 256 bit encryption
All parts of the internal infrastructure transmit their logs to a centralized log aggregator for inspection and analysis.
Red Hat Security conducts regular architecture review of infrastructure
Data is always encrypted in transit.
All API calls for reading and writing data must be authenticated.
All software is analyzed with static code analyzers and all reported issues are fixed before code is deployed into production.
Code is peer reviewed.
Development teams follow an Agile software delivery lifecycle, which means that security related defects can be addressed rapidly, and software patches are regularly released as part of our continuous delivery model.
Patches that can impact end users will be applied as soon as possible, but may necessitate end user notification and scheduling a service window in some cases.
All infrastructure software components are continuously monitored for known vulnerabilities (CVEs) and proactively patched.
Penetration testing is conducted by both internal and external parties.
Access to systems that handle customer data is controlled via multi factor authentication and authorization controls. Access is granted on a need to know basis.