The Journey to Security Automation
Whether you’re a security professional looking at automation for the first time, or an ITops veteran tasked to support corporate secops teams, the following blog provides an overview of how Red Hat Ansible Automation can support your security automation program throughout all the different stages of its evolution.
Security Automation: A maturity model
Automation is becoming more and more pervasive across the entire IT stack.
Initially introduced to support ITOps, automation has been a well-established practice for years.
Today, thanks to modern automation platforms like Red Hat Ansible Automation, IT organizations are more capable of coping with the unprecedented scale, and complexity of modern infrastructures and finally have access to a level of flexibility that allows for extending automation practices to entirely new areas.
As an example, Ansible Network Automation enabled network operators to be the next group approaching automation in a structured fashion, to help simplify both maintenance and operations of their ever-growing, multi-vendor, brownfield infrastructures.
The security space started looking at automation in relatively recent times to support the already overwhelmed security teams against modern cyberattacks that are reaching an unparalleled level of speed and intricacy.
In fact, if we factor in the aforementioned scale Continue reading
Introducing Red Hat Ansible Automation Platform
We are excited to introduce 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.
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.
We’ve 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 Continue reading
Ansible Security Automation is our 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.
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 Continue reading
AnsibleFest Atlanta – Tech Deep Dives
Only one more week until AnsibleFest 2019 comes to Atlanta! We talked with Track Lead Sean Cavanaugh to learn more about the Technical Deep Dives track and the sessions within it.
Who is this track best for?
You've written playbooks. You've automated deployments. But you want to go deeper - learn new ways you could use Ansible you haven't thought of before. Extend Ansible for new functionality. Dig deep into new use cases. Then Tech Deep Dives is for you. This track is best suited for someone with existing Ansible knowledge and experience that already knows the nomenclature. It is best for engineers who want to learn how to take their automation journey to the next level. This track includes multiple talks from Ansible Automation developers, and it is your chance to ask them direct questions or provide feedback.
What topics will this track cover?
This track is about automation proficiency. Talks range from development and testing of modules and content to building and operationalizing automation to scale for your enterprise. Think about best practices, but then use those takeaways to leverage automation for your entire organization.
What should Continue reading
AnsibleFest Atlanta – Ansible Automation
AnsibleFest is right around the corner and we are excited to go to Atlanta! We talked with Track Lead Colin McNaughton to learn more about the Ansible Automation track and the sessions within it.
Who is this track best for?
This track is best for existing users, story-tellers, curious adopters and enterprise architects.
What topics will this track cover?
This track will include conversations and presentations guided by existing Ansible Automation customers. Sessions in this track will expand on how the application of key components of Ansible change along the road to enterprise adoption of Ansible Automation. Attend sessions in this track to learn about how others manage inventories, create cloud infrastructure defined as code, and other lessons learned from real world deployments.
What should attendees expect to learn from this track?
Attendees can expect to hear stories from real world experience in automating in diverse ecosystems and discussions around applying and scaling core tenets of Ansible Automation.
Where would you expect to find attendees to this track to hangout online?
If attendees are looking to learn more or have questions after AnsibleFest, online communities like message board style communities, Continue reading
AnsibleFest Atlanta – Culture and Collaboration
Now that AnsibleFest is right around the corner, we wanted to take a closer look at each of the tracks that we will offer. We talked with Track Lead Brian Coursen and asked him a few questions about the Culture and Collaboration Track and sessions within the track.
Who is this track best for?
This track is best for attendees that want to see how Ansible is used and how it brings people and teams together in the workplace.
What topics will this track cover?
Topics will include how to create an automation culture as well as highlight some automation use cases. This will include minimizing business unit conflict with patch automation, how to build an open source network service orchestrator using Ansible at the core, and why automation isn't just a passing fad but a necessity in today's enterprise.
What should attendees expect to learn from this track?
Attendees will learn about DevOps culture and automation. They will also learn about how places like National Weather Service Southern Region; Datacom; and the British financial institution, RBS, are all using Ansible to create a culture of collaboration.
Where would you Continue reading
AnsibleFest Atlanta – Infrastructure Automation
AnsibleFest is only a few short weeks away and we are excited to share with you all the great content and sessions we have lined up! On the Ansible blog, we have been taking a closer look at each of the breakout session tracks so that attendees can better personalize their AnsibleFest experience. We sat down with Track Lead Dylan Silva to find out more about the Infrastructure Automation Track and sessions within the track.
Who is this track best for?
This track is best for sysadmins that are looking for information related to general infrastructure automation with Ansible.
What topics will this track cover?
Sessions in this track will cover bare-metal, server administration, and inventory management, among other related topics. There will be a session covering the automation of VMware infrastructure using REST APIs, how to use Ansible against your vSphere environment, how to use Ansible to pull approved firewall change requests from our change management system, and much more.
What should attendees expect to learn from this track?
Attendees should expect to learn best practices related to infrastructure management. This includes scaling Ansible for loT deployments, taking a closer Continue reading
AnsibleFest Atlanta – Ansible Integrations
With AnsibleFest less than a month away we wanted to take a closer look at each of the session tracks to help you make your experience as personalized as possible. We talked with Track Lead Bill Nottingham and asked him a few questions about the Ansible Integrations Track and sessions within the track.
Who is this track best for?
In Ansible Integrations, we’re highlighting integrations of Ansible with other technologies. This track is best for people who manage a large variety of varied infrastructure, and are interested in how Ansible can help manage in new areas. It’s also useful for those interested in building integrations with Ansible for their own platforms.
What topics will this track cover?
In Ansible Integrations, we’ll highlight the impact of Ansible combined with a variety of technologies and use cases. We will highlight how Ansible allows easy management of application lifecycles, how Ansible helps enable management of containers in the public cloud, how XLAB worked to build certified collections for Ansible, how to customize your base operating system image and much more!
What should attendees expect to learn from this track?
Attendees should expect to learn Continue reading
AnsibleFest Atlanta – Security Automation
Security Automation seems to be a growing topic of interest. This year at AnsibleFest we will have a track for Security Automation. We talked with Track Lead Massimo Ferrari to learn more about the Security Automation track and the sessions within it.
Who is this track best for?
This track is intended for professionals in security operations and vulnerability management who want to learn how Ansible can support and simplify their activities, and automation experts tasked to expand the footprint of their automation practice and support security teams in their organization.
What topics will this track cover?
Sessions included in this track cover how to introduce and consume Ansible Automation in different stages of maturity of a security or cross-functional organization. They include guidance from Red Hat subject matter experts, customer stories and technical deep downs from partners that are suitable for both automation veterans and security professionals looking at automation for the first time.
What should attendees expect to learn from this track?
People attending the sessions in this track will learn how Ansible can be leveraged in security environments to support activities like incident investigation and response, compliance enforcement and Continue reading
AnsibleFest Atlanta – Getting Started
On Wednesday we took a closer look at the Networking Automation track. Soon you will be able to start building out your schedule for AnsibleFest, so we want to help you figure out what tracks and sessions will be best for you! We talked with Track Lead Jake Jackson to learn more about the Getting Started track and the sessions within it.
Who is this track best for?
This track is best for people who are new to Ansible, whether that is in application or in concept. Many of these breakout sessions are introductory in nature for people who want to learn more about Ansible and how it works.
What topics will this track cover?
This track will cover several topics. It includes introductions to Ansible and Ansible Tower, and a deeper dive into Ansible inventories. It also discusses bite-size ways to automate and manage Windows the same way you would linux. There will also be a session that introduces using Ansible in CI and analyzing roles.
What should attendees expect to learn from this track?
Attendees can expect to learn the basics of Ansible and Ansible Tower from this track. They Continue reading
AnsibleFest Atlanta – Network Automation
Now that the agenda for AnsibleFest is live, we wanted to take a closer look at each of the tracks that we will offer. Soon you will be able to start building out your schedule for AnsibleFest, so we want to help you figure out what tracks and sessions will be best for you! We talked with Track Lead Andrius Benokraitis to learn more about the Network Automation track and the sessions within it.
Who is this track best for?
This track is best for Network Operators, Network Engineers, Cloud Operators, and DevOps Engineers. It is great for people who are looking to learn more about automating the configuration, management and operations of a computer network.
What topics will this track cover?
This track will cover topics that include operational application of Red Hat Ansible Automation for network use cases, including devices such as: switches, routers, load balancers, firewalls. We will also be discussing different point of views: Developer of modules vs. User and implementer of modules and roles. There will also be a discussion around how enterprises are using Ansible Automation as a platform for large scale network deployments.
What should attendees expect Continue reading
AnsibleFest Atlanta – Here We Come!
AnsibleFest Atlanta is September 24th - 26th at the Hilton Atlanta, a few short blocks from Centennial Olympic Park. This year is going to be bigger and better than ever. As AnsibleFest continues to grow, so does its offerings. We are excited to offer more breakout sessions, more hands-on workshops, and more Ask an Expert sessions. This year we have expanded our AnsibleFest programming to offer 10 different tracks. We are also introducing the Open Lounge this year, which is a place to network, relax and recharge. It provides a great opportunity to meet and connect with passionate Ansible users, developers, and industry partners.
The AnsibleFest Agenda is live. Thank you to everyone who answered the call for submission. It was a challenge to narrow down the sessions from the record-setting submissions we received. We love our community, customers, partners, and appreciate everyone who contributed.
For those who are not familiar with AnsibleFest, or have not attended the event before, below are a few highlights of AnsibleFest that you won’t want to miss.
General Sessions
We have some amazing general sessions planned this year. The opening keynote at AnsibleFest will feature talks from Red Hat Ansible Automation Continue reading
Kubernetes Operators with Ansible Deep Dive: Part 2
In part 1 of this series, we looked at operators overall, and what they do in OpenShift/Kubernetes. We peeked at the Operator SDK, and why you'd want to use an Ansible Operator rather than other kinds of operators provided by the SDK. We also explored how Ansible Operators are structured and the relevant files created by the Operator SDK when building Kubernetes Operators with Ansible.
In this the second part of this deep dive series, we'll:
- Take a look at creating an OpenShift Project and deploying a Galera Operator
- Next we’ll check the MySQL cluster, then setup and test a Galera cluster
- Then we’ll test scaling down, disaster recovery, and demonstrate cleaning up
Creating the project and deploying the operator
We start by creating a new project in OpenShift, which we'll simply call test:
$ oc new-project test --display-name="Testing Ansible Operator" Now using project "test" on server "https://ec2-xx-yy-zz-1.us-east-2.compute.amazonaws.com:8443".
We won't delve too much into this role, however the basic operation is:
- Use set_fact to generate variables using the k8s lookup plugin or other variables defined in defaults/main.yml.
- Determine if any corrective action needs to be taken based on the above variables. For example, one Continue reading
Kubernetes Operators with Ansible Deep Dive: Part 1
This deep dive series assumes the reader has access to a Kubernetes test environment. A tool like minikube is an acceptable platform for the purposes of this article. If you are an existing Red Hat customer, another option is spinning up an OpenShift cluster through cloud.redhat.com. This SaaS portal makes trying OpenShift a turnkey operation.
In this part of this deep dive series, we'll:
- Take a look at operators overall, and what they do in OpenShift/Kubernetes.
- Take a quick look at the Operator SDK, and why you'd want to use an Ansible operator rather than other kinds of operators provided by the SDK.
- And finally, how Ansible Operators are structured and the relevant files created by the Operator SDK.
What Are Operators?
For those who may not be very familiar with Kubernetes, it is, in its most simplistic description - a resource manager. Users specify how much of a given resource they want and Kubernetes manages those resources to achieve the state the user specified. These resources can be pods (which contain one or more containers), persistent volumes, or even custom resources defined by users.
This makes Kubernetes useful for managing resources that don't contain any state (like Continue reading
Thoughts on Restructuring the Ansible Project
Ansible became popular largely because we adopted some key principles early, and stuck to them.
The first key principle was simplicity: simple to install, simple to use, simple to find documentation and examples, simple to write playbooks, and simple to make contributions.The second key principle was modularity: Ansible functionality could be easily extended by writing modules, and anyone could write a module and contribute it back to Ansible.
The third key principle was “batteries included”: all of the modules for Ansible would be built-in, so you wouldn’t have to figure out where to get them. They’d just be there.
We’ve come a long way by following these principles, and we intend to stick to them.
Recently though, we’ve been reevaluating how we might better structure Ansible to support these principles. We now find ourselves dealing with problems of scale that are becoming more challenging to solve. Jan-Piet Mens, who has continued to be a close friend to Ansible since our very earliest days, recently described those problems quite succinctly from his perspective as a long-time contributor -- and I think his analysis of the problems we face is quite accurate. Simply, we’ve become victims of our own success.
Success Continue reading
The Future of Ansible Content Delivery
Everyday, I’m in awe of what Ansible has grown to be. The incredible growth of the community and viral adoption of the technology has resulted in a content management challenge for the project.
I don’t want to echo a lot of what’s been said by our dear friend Jan-Piet Mens or our incredible Community team, but give me a moment to take a shot at it.
Our main challenge is rooted in the ability to scale. The volume of pull requests and issues we see day to day severely outweigh the ability of the Ansible community to keep up with that rate of change.
As a result, we are embarking on a journey. This journey is one that we know that the community, both our content creators and content consumers, will be interested in hearing about.
This New World Order (tongue in cheek), as we’ve been calling it, is a model that will allow for us to empower the community of contributors of Ansible content (read: modules, plugins, and roles) to provide their content at their own pace.
To do this, we have made some changes to how Ansible leverages content that is not “shipped” with it. In short, Continue reading
Ansible + ServiceNow Part 2: Parsing facts from network devices using PyATS/Genie
This blog is part two in a series covering how Red Hat Ansible Automation can integrate with ticket automation. This time we’ll cover dynamically adding a set of network facts from your switches and routers and into your ServiceNow tickets. If you missed Part 1 of this blog series, you can refer to it via the following link: Ansible + ServiceNow Part 1: Opening and Closing Tickets.
Suppose there was a certain network operating system software version that contained an issue you knew was always causing problems and making your uptime SLA suffer. How could you convince your management to finance an upgrade project? How could you justify to them that the fix would be well worth the cost? Better yet, how would you even know?
A great start would be having metrics that you could track. The ability to data mine against your tickets would prove just how many tickets were involved with hardware running that buggy software version. In this blog, I’ll show you how to automate adding a set of facts to all of your tickets going forward. Indisputable facts can then be pulled directly from the device with no chance of mistakes or accidentally being overlooked Continue reading
The Song Remains The Same
Now that Red Hat is a part of IBM, some people may wonder about the future of the Ansible project. Here is the good news: the Ansible community strategy has not changed.
As always, we want to make it as easy as possible to work with any projects and communities who want to work with Ansible. With the resources of IBM behind us, we plan to accelerate these efforts. We want to do more integrations with more open source communities and more technologies.
One of the reasons we are excited for the merger is that IBM understands the importance of a broad and diverse community. Search for “Ansible plus <open source project>” and you can find Ansible information, such as playbooks and modules and blog posts and videos and slide decks, intended to make working with that project easier. We have thousands of people attending Ansible meetups and events all over the world. We have millions of downloads. We have had this momentum because we provide users flexibility and freedom. IBM is committed to our independence as a community so that we can continue this work.
We’ve worked hard to be good open source citizens. We value the trust Continue reading
Kubernetes Operators with Ansible Deep Dive: Part 1
Deploying applications on Red Hat OpenShift or Kubernetes has come a long way. These days, it's relatively easy to use OpenShift's GUI or something like Helm to deploy applications with minimal effort. Unfortunately, these tools don't typically address the needs of operations teams tasked with maintaining the health or scalability of the application - especially if the deployed application is something stateful like a database. This is where Operators come in.
An Operator is a method of packaging, deploying and managing a Kubernetes application. Kubernetes Operators with Ansible exists to help you encode the operational knowledge of your application in Ansible.
What can we do with Ansible in a Kubernetes Operator? Because Ansible is now part of the Operator SDK, anything Operators could do should be able to be done with Ansible. It’s now possible to write an Operator as an Ansible Playbook or Role to manage components in Kubernetes clusters. In this blog, we're going to be diving into an example Operator.
For more information on Kubernetes Operators with Ansible please refer to the following resources:
Configure Network Cards by PCI Address with Ansible Facts
In this post, you will learn advanced applications of Ansible facts to configure Linux networking. Instead of hard-coding device names, you will find out how to specify network devices by PCI addresses. This prepares your configuration to work on different Red Hat Enterprise Linux releases with different network naming schemes.
Red Hat Enterprise Linux System Roles
The RHEL System Roles provide a uniform configuration interface across multiple RHEL releases. However, the names of network devices in modern Linux distributions can often not be stable for various releases. In the past, the kernel named the devices after their order of appearance. The first device got the name eth0, the next eth1, and so on.
To make the device names more reliable, developers introduced other methods. This interferes with creating a release-independent network configuration based on interface names. An initial solution to this problem is to address network cards by MAC address. But this will require an up-to-date inventory with MAC addresses of all network cards. Also, it requires updating the inventory after replacing broken hardware. This results in extra work. To avoid this effort, it would be great to be able to specify network cards by their PCI address. Continue reading