• IBM Consulting

    DBA Consulting can help you with IBM BI and Web related work. Also IBM Linux is our portfolio.

  • Oracle Consulting

    For Oracle related consulting and Database work and support and Migration call DBA Consulting.

  • Novell/RedHat Consulting

    For all Novell Suse Linux and SAP on Suse Linux questions releated to OS and BI solutions. And offcourse also for the great RedHat products like RedHat Enterprise Server and JBoss middelware and BI on RedHat.

  • Microsoft Consulting

    For Microsoft Server 2012 onwards, Microsoft Client Windows 7 and higher, Microsoft Cloud Services (Azure,Office 365, etc.) related consulting services.

  • Citrix Consulting

    Citrix VDI in a box, Desktop Vertualizations and Citrix Netscaler security.

  • Web Development

    Web Development (Static Websites, CMS Websites (Drupal 7/8, WordPress, Joomla, Responsive Websites and Adaptive Websites).

16 January 2020

INTRODUCING RED HAT ANSIBLE AUTOMATION PLATFORM


RED HAT ANSIBLE AUTOMATION PLATFORM

Red Hat Ansible Automation Platform, a new offering that combines the simple and powerful Ansible solutions with new capabilities for cross-team collaboration, governance and analytics, resulting in a platform for building and operating automation at scale.

Managing 15,000 network devices with Ansible


Over the past several years, we’ve listened closely to the community, customers and partners and their needs. We’ve also looked carefully at how the market is changing and where we see automation headed. One of the most common requests we’ve heard from customers is the need to bring together separate teams using automation. Today’s organizations are often automating different areas of their business (such as on-premises IT vs. cloud services vs. networks) each with their own set of Ansible Playbooks and little collaboration between the different domains. While this may still get the task accomplished, it can be a barrier to realizing the full value of automation.



Red Hat also found that even within a single organization, teams are often at different stages of automation maturity. Organizations are often recreating the wheel - automating processes that have already been done.



Organizations need a solution they can use across teams and domains, and a solution they can grow with as they progress on their automation journey. This is why we saw a need for Red Hat Ansible Automation Platform. It’s a single automation solution designed to bring teams together, allow organizations to scale, and exponentially increase the value of automation.

Smarter, Scalable, More Shareable Automation

Red Hat Ansible Automation Platform brings together Red Hat Ansible Engine, Red Hat Ansible Tower and Red Hat Ansible Network Automation along with new capabilities including Certified Content Collections, Automation Hub, Automation Analytics, and more, all in a single subscription.

 Subscription Management using Red Hat Satellite (and demonstration)


Red Hat combined support for our current product offerings and add-ons for a simplified, streamlined adoption process for our customers. Red Hat Ansible Automation Platform provides features to accelerate the time to realizing business value with automation. The new capabilities, including Ansible Content Collections, Automation Hub and Automation Analytics, help to drive a more consistent automation user experience and fuel better collaboration to solve more IT challenges.

 Introduction to Red Hat Smart Management


The depth and breadth of content available for automation with Ansible can be a significant driver of success. That content comes from our vibrant community, customers, Red Hat, and from our partners, all helping to support and strengthen the Ansible community. However, as Ansible becomes more mature and used by more enterprise customers, the lifecycle of Ansible requires slowing down for stability. Even until fairly recently, we would cut a major release of Ansible every four months, but our most recent release cycle was eight months -- and that slower release cycle will now become the rule going forward. This means that it will take longer for new content to reach users. It also is especially constraining for our partners as they would only be able to update their modules and plug-ins on our schedule. This is why we knew we needed to make a change.

Introduction to Red Hat Insights


 JOURNEY MAP APPROACH TO IMPLEMENTING NETWORK AUTOMATION WITH ANSIBLE

https://www.ansible.com/journey-map-approach-to-implementing-network-automation-with-ansible

Ansible Content Collections is a new packaging format for managing and consuming Ansible Content. It provides quick benefits by lowering barriers to automation. Collections organizes Ansible content including, modules, plugins, roles, documentation and playbooks, making it easier for customers and contributors to distribute, share and consume content independent of Ansible release cycles.

 Red Hat Subscriptions Management 101




Ansible Content Collections also helps with user efficiency. It provides access to already packaged and certified Ansible content, making it easier for content creators to build focused, defined packages of content and for users to consume those fully formed solutions. Additionally, supported, pre-composed partner content will be made available via Collections, helping users to more quickly and easily get started with automation.

 Performance analysis and tuning of Red Hat Enterprise Linux - Part 1


Red Hat also are introducing Automation Hub. Automation Hub is a repository for users to discover certified, supported Ansible Content Collections. Often, we see our customers pulling content from the community, which may or may not comply with their internal standards. Using unsupported content may initially speed up a specific project, but for some this is not always an acceptable risk. Automation Hub provides a one-stop-shop for Ansible content that is backed by support from Red Hat and its partners to deliver additional reassurance for the most demanding environments.

 Performance analysis and tuning of Red Hat Enterprise Linux - Part 2


To provide users more insight around the health and performance of their automation, we are launching Automation Analytics. Accelerating automation across an organization requires powerful analytics. Automation Analytics provides customers with enhanced knowledge and detail around their automation initiatives, including statistics and data around modules and resources that are used most often, the health of automation and how an automation environment is performing. In the future, we plan to continue to add to these capabilities to provide organization an even more in-depth look at their automation across all domains.

Enabling an Automation Center of Excellence

Red Hat Ansible Automation Platform is more than just the Ansible products you know today. To do automation at scale, users need more than features, they need a breadth of capabilities that maintain the same ethos around simplicity and power that Ansible was built on. With the Platform, users have a common automation language that creates a standardized experience for solving problems, scaling and managing automation policies and governance -- which is why we believe that Forrester named Red Hat Ansible Automation a Leader in The Forrester Wave™: Infrastructure Automation Platforms, Q3 2019.

 Accelerating with Ansible



Red Hat are excited for the Platform to be generally available and to see how our customers make use of the new capabilities to automate across their enterprise. Scheduled to be available in early November, customers with a current Red Hat Ansible Tower or Red Hat Ansible Engine subscription can upgrade to the latest versions of the product for access to Red Hat Ansible Automation Platform. The features will be available to customers through cloud.redhat.com, a Software-as-a-Service (SaaS)-based portal.


Red Hat ANSIBLE Products:

- ANSIBLE PROJECT

- RED HAT ANSIBLE TOWER

- ANSIBLE NETWORK

- ANSIBLE GALAXY

- ANSIBLE LINT


ANSIBLE SECURITY AUTOMATION IS RED HAT'S ANSWER TO THE LACK OF INTEGRATION ACROSS THE IT INDUSTRY
In 2019, CISOs struggle more than ever to contain and counter cyberattacks despite an apparently flourishing IT security market and hundreds of millions of dollars in venture capital fueling yearly waves of new startups. Why?

If you review the IT security landscape today, you’ll find it crowded with startups and mainstream vendors offering solutions against cybersecurity threats that have fundamentally remained unchanged for the last two decades. Yes, a small minority of those solutions focus on protecting new infrastructures and platforms (like container-based ones) and new application architecture (like serverless computing), but for the most part, the threats and attack methods against these targets have remained largely the same as in the past.

Red Hat Cloud Infrastructure


This crowded market, propelled by increasing venture capital investments, is challenging to assess, and can make it difficult for a CISO to identify and select the best possible solution to protect an enterprise IT environment. On top of this, none of the solutions on the market solve all security problems, and so the average security portfolio of a large end user organization can often comprise of dozens of products, sometimes up to 50 different vendors and overlap in multiple areas.

Despite the choices, and more than three decades of experience to refine how security solutions should address cyberattacks, various research studies and surveys describe a highly inefficient security landscape. VentureBeat, for example, reported that, “the average security team typically examines less than 5% of the alerts flowing into them every day.” In another example, Cisco reported that of all legitimate alerts generated by security solutions, only 51% of them are remediated. As a final example, The Ponemon Institute reported that 57% of interviewed organizations said the time to resolve an incident has increased, while 65% of them reported that the severity of attacks has increased.



So why do we struggle to counter cyberattacks?

A full analysis of the state of the security industry goes beyond the purpose of this blog post, and we certainly believe that there's concurrence of causes, but we also believe that one of the main factors impacting CISOs capability to defend their IT infrastructures is the lack of integration between the plethora of security solutions available in the market.

The products that CISOs buy and implement as part of their security arsenals are almost never working in an orchestrated way because, by design, they don’t talk to each other. Occasionally, 2-3 products could share data if they are delivered by the same security vendor or if, temporarily, there’s a technology collaboration between the manufacturers. However, for the most part, the IT security solutions out there are completely disjointed from each other. Which is, to use an analogy, like saying that we invested in multiple security solutions to protect a commercial building, such as a CCTV system, security guards, and patrol dogs. But, the security guards don’t look at the CCTV cameras and the patrol dogs are kept locked in the basement.

How can we fix this industry-wide lack of integration?

In an ideal world, the whole security industry would embrace an open standard (there have been many proposals on the table for years) and each security solution out there would embrace that standard allowing any software or hardware solution to orchestrate the CISO arsenal in a harmonious assessment or remediation plan. Unfortunately, it seems we are still far from that day.

AUTOMATION DOESN'T REPLACE YOUR JOB, IT STRENGTHENS YOUR POSITION - Bill Hirsch


Until then, the idea is to leverage IT automation as a connecting tissue between security solutions across various industry categories, from enterprise firewalls to intrusion detection systems (IDS) to security information and management (SIEM) solutions, and many others. If security products across these categories can be individually automated through a common automation language, then the latter can be used as the “lingua franca” to express an orchestrated remediation plan.

To succeed, we believe that this plan requires an automation language that has three fundamental characteristics:

It is already widespread and highly adopted across the IT industry, to minimize the implementation friction
It is not in control of any security player, to maintain an unbiased approach to solving the problem
It can be easily extended by any industry constituency, to integrate and support a long tail of security solutions out there



The industry can already count on a similar automation language: Ansible. As an open source automation platform and language, Ansible already integrates with a wide range of security solutions (and network solutions, and infrastructure solutions, and much more) and is driven forward by a global community of thousands. Ansible, in fact, is the 7th most contributed open source project worldwide on GitHub according to the 2018 Octoverse report.

At Red Hat, we believe that Ansible could become a de facto standard in integrating and automating the security ecosystem and we stand by this belief by committing commercial support for a number of enterprise security solutions widely used by CISOs around the world.

What can we do when multiple security solutions are integrated through automation?

Security analysts around the world understand how difficult it is to conduct an investigation about an application’s suspicious behaviour. Security operators know how difficult it is to stop an ongoing attack before it’s too late or how to remediate the mayhem caused by a successful one.

When every solution in a security portfolio is automated through the same language, both analysts and operators can perform a series of actions across various products in a fraction of the time, maximizing the overall efficiency of the security team.

The foundation for digital transformation: Red Hat Cloud Suite



For example, a security analyst that must evaluate suspicious behaviour from a production server, might need to increase the verbosity of the logs across all deployed firewalls and/or enable a rule on the deployed IDS to better understand who’s doing what and why. This seemingly trivial activity often involves the collaboration of multiple security professionals across the organization and can be slowed down by a series of support tickets/emails/phone calls to explain and justify what to do and how.

Red Hat Insights


A pre-existing, pre-verified, pre-approved automation workflow (an Ansible Playbook in our case), that security analysts could launch anytime they are conducting an investigation, could significantly reduce that inefficiency.

This is just one of the use cases that we’ll support. At the launch of Ansible security automation, with the upcoming release of Ansible Automation, we’ll deliver the integration with enterprise security solutions across multiple product categories:


Enterprise Firewalls

  • Check Point Next Generation Firewall
  • Fortinet Next Generation Firewall
  • Cisco Firepower Threat Defense


Intrusion Detection & Prevention Systems

  • Check Point Intrusion Prevention System
  • Fortinet Intrusion Prevention System
  • Snort


Privileged Access Management

  • CyberArk Privileged Access Security


Security Information & Events Management

  • IBM QRadar SIEM
  • Splunk Enterprise Security


Over time, we plan to extend support to more security categories and more products across those categories. In fact, security vendors are welcome to reach out to us and explore how we can cooperate to increase the efficiency of security solutions out there.

If you are interested in the details of how Ansible security automation works, we have an entire security track at AnsibleFest Atlanta 2019 from Sept 24-26, 2019. Let’s meet there: https://www.ansible.com/ansiblefest



Much has been written about Red Hat Satellite 6, Red Hat’s long-standing enterprise server fleet management product, and Ansible Tower, Red Hat’s choice automation engine.
Despite obvious overlap between what both technologies do (configuration management, remote execution, node classification etc.), neither is a drop-in replacement for the other, and each is capable in ways the other is not.
Why is this needed?

Setting up infrastructure (be that physical, virtual or cloud) while providing teams with control planes accounting for everything that changes on each client system -
the state systems are born into (provisioning) the content, methods and cadence used to update them over time (patching)
what configuration and customisation they receive to be able do their job (CM) and what security bar they empirically meet (compliance)
… all while meeting the changing and evolving needs of their application workload
… can be a daunting and complex task. By meeting these requirements, not only do we hit the lot, but to a degree, we divorce the scale from management costs by making all of it fair game for automation.

Journey map approach to implementing network automation with ansible ansible fest 2019



This blog will discuss an integrated Red Hat Satellite and Ansible Tower solution architecture that addresses the following 4 (and optional fifth) requirements:

1. Use a single product to act as source of truth for facts driving provisioning, patching and configuration management.
2. Define all settings using a fleet hierarchy that supports nesting and inheritance.
3. Provide the user with a push-driven configuration management system.
4. Provide the user with workflow management that can perform actions on multiple systems within a single workflow.
5. (Optional) Often a direct preference requirement requests Ansible. If explored, the underlying requirement is either lower time/labor costs in deploying new or servicing existing automation, or intention to extend the solution to deploy immutable infrastructure for cloud-native applications.

Hack your way to cloud!



Putting on our solution hats, Red Hat Satellite 6 hits the first two requirements head-on, however its native configuration management system, Puppet, fails on requirements 3–5.
Ansible Tower hits the last three, but trails behind when it comes to constructing all the content and server-side stuff a healthy client system needs, specifically for provisioning and patching.
Last, Satellite and Ansible Tower without integration fails requirement number one.
The solution meeting the lot is smart integration of the two products, leveraging the strengths of each.





A High Level Overview of the Deployment Process

1. Deploy Satellite

Red Hat Satellite should be configured with the appropriate Products, Content Views, Life Cycle Environments and Activation Keys.
Hostgroups are important in this process, as they define a host’s Life Cycle Environment, Content View, Content Source, Operating system specifics and parameters specific to the host that will be exposed to Ansible Tower as inventory facts. Hostgroups can be nested, allowing certain settings to be inherited from the parent Hostgroup by a child Hostgroup.

What's New in Red Hat Satellite


The Hostgroup tree should thus also be set up. For example, a single location/content-source tree for one operating system (omitting application customisation “leaves”) may look as follows:

soe-rhel7
soe-rhel7\sandbox
soe-rhel7\nonprod
soe-rhel7\prod

Finally, a service account should be created in Red Hat Satellite 6 to allow Ansible Tower to interrogate Satellite.

Red Hat Satellite Technical Overview (RH053): Introduction to Red Hat Satellite



2. Deploy Ansible Tower

Ansible Tower should be configured to use Satellite 6 as a dynamic inventory source. Support for this is already included in recent versions of Ansible Tower, and can be set up by
Cog -> Credentials -> Add -> Credential Type: Red Hat Satellite 6
Inventories -> Add, give the inventory a name and Save

In the Inventory select the Sources -> Add Source -> in the Source box pick Red Hat Satellite 6, and in Credential, pick the set configured in step a above.

That’s all it takes. Satellite and Ansible Tower now effectively share a brain.

As the Dynamic Inventory represents all clients in Red Hat Satellite, it should not be used directly in Job Templates or Workflows.

Smart Inventories (filtered versions of the main Dynamic Inventory) should be used by Job and Workflow Templates.

Filtering used to define Smart Inventories can be based on
- a parameter set during the provisioning process (and subsequently removed), to perform provisioning steps only on that one system at that part of its provisioning flow.
- a different parameter can be set once the client is operationalised, to include it in periodic configuration management runs on groups of systems.

This is done using the following as the Smart Host Filter definition in the Smart Inventory:
variables.icontains:

Note that what satisfies this criteria is whether the specified parameter is defined in Foreman, rather than its value. Using this method, parameters can be used as flags, determining whether hosts are included in the Smart Inventory that a job runs on, or not.

Developing In Python On Red Hat Platforms (Nick Coghlan & Graham Dumpleton)



The importance of filtering hosts from a Dynamic Inventory rather from just listing them in a regular inventory (or deriving them from other sources, like a Dynamic Inventory from the virtualisation layer) is the key that enables this architecture. When the host is thus pulled from the Satellite 6 Dynamic Inventory, its record brings in all the host’s Satellite settings (e.g. Content View, Life Cycle Environment, etc.).

All the host’s Foreman parameters, as set in Satellite, using either simple (global, per-Organisation/Location/Domain, Hostgroup tree or host “inherit-or-override” logic) or smart (user-specified fact-based logic) parameter values.

Camel Riders in the Cloud


Big data insights with Red Hat JBoss Data Virtualization


More Information:

https://www.redhat.com/en/technologies/management/ansible

https://docs.ansible.com/?extIdCarryOver=true&sc_cid=701f2000001OH6uAAG&intcmp=7013a000002CxGXAA0

https://www.ansible.com/blog/topic/security-automation

https://www.ansible.com/blog/topic/security-and-compliance

https://www.ansible.com/blog/security-and-delegation-with-ansible-tower-part-1

https://www.ansible.com/blog/simple-self-service-with-ansible-and-tower (part-2)

https://access.redhat.com/documentation/en-us/red_hat_satellite/6.4/html/planning_for_red_hat_satellite_6/chap-red_hat_satellite-architecture_guide-introduction_to_red_hat_satellite

https://www.redhat.com/en/about/press-releases/red-hat-openstack-platform-15-enhances-infrastructure-security-and-cloud-native-integration-across-open-hybrid-cloud?intcmp=7013a000002CxGXAA0

https://access.redhat.com/products/red-hat-satellite#knowledge

https://access.redhat.com/products/red-hat-satellite#whatsnew

https://medium.com/accountable-design/red-hat-satellite-and-ansible-tower-53c2cd1626f6

https://www.zdnet.com/article/red-hat-jumps-into-devops-by-buying-ansible/