With the released timed to KubeCon, NeuVector – which focuses on container security throughout the full application lifecycle – has announced the industry’s first “Security Policy as Code” capability for Kubernetes services.

 The new release gives DevOps teams a way to automate container security using Kubernetes Customer Resource Definitions (CRDs) to define and manage application security policy throughout both development and production.

What this means is that DevOps (and DevSecOps) teams can more quickly deliver secure cloud-native apps through security policies that can be defined, managed and automated during the DevOps process. NeuVector has been continuing to expand its container security platform, most recently adding data loss prevention (DLP) and multi-cluster/multi-cloud management capabilities.

Gary Duan, NeuVector’s Chief Technology Officer, discussed the new release: “By introducing our industry-first Security Policy as Code for Kubernetes workloads, we’re excited to provide DevOps and DevSecOps teams with even more control to automate safe behaviors and ensure their applications remain secure from ever-increasing threat vectors. We continue to build out new capabilities sought by customers – such as DLP, multi-cluster management, and, with today’s release, CRD support. Our mission is acutely focused on raising the bar for container security by offering a complete cloud-native solution for the entire application lifecycle.”

With Security Policy as Code, DevOps teams can now implement robust security policies using CRDs to deploy customized resource configurations via developer-friendly YAML files. NeuVector also enables DevOps teams to create CRDs that capture the full profile of application behavior – and do so in a Kubernetes-native way. The result is security policy enforcement that:

1. Captures the entire application behavior, including network rules, protocols, processes, and file activities that are allowed – or ‘whitelisted’ – for the application.
2. Only permits allowed network connections between services – enforced by application protocol (layer 7) inspection.
3. Allows or prevents external or ingress connections as warranted.
4. Sets the “protection mode” of the application to either Monitor mode (alerting only) or Protect mode (blocking all suspicious activity).
5. Supports integration with Open Policy Agent(OPA) and other security policy management tools.
6. Allows DevOps and security teams to define application policies at different hierarchies such as per-service rules defined by DevOps and global rules defined by centralized security teams.
7. Is RBAC-enabled, enforcing the creation and updates of security policy as allowed natively by Kubernetes service accounts and roles.

8.Is extensible, to support future expansion of security policy as code to admission control rules, DLP rules, response rules and other NeuVector enforcement policies.

Using Security Policy as Code and CRDs, DevOps teams can define and allow the run-time application behavior they expect by implementing specific security rules for network connections, process activity, file access patterns, and other run-time policies. Because these security policies are defined as code, they are version-tracked and built for automation. This helps DevOps teams who are migrating security policies across Kubernetes clusters (or from staging to production environments), and when managing versions of security policies tied to specific application versions. DevOps teams can also enforce global security policies this way, and further specify policies for each Kubernetes workload as needed.

NeuVector’s behavioral learning technology brings the ability to learn and define appropriate application behavior in testing or staging environments, and to export that security policy as a CRD YAML file that developers and DevOps teams can review and edit before deploying in production. Combined with NeuVector’s full lifecycle vulnerability scanning and ConfigMap-based deployment capabilities, CRD support from NeuVector adds to security automation during the entire CI/CD pipeline and into production environments.

“Security continues to shift left, and our Platform teams are eager to manage security policy as code,” said Sean McCormick, VP of Engineering at Element. “Doing so enables us to automate security further upstream – simplifying and hardening policy enforcement. With its Security Policy as Code support, NeuVector gives us a more granular capacity to centrally manage our security policies without needing to configure them through a UI. This is a significant improvement for Element, allowing us to maintain policy consistency across all customer and development environments.”

The post NeuVector’s security policy as code for Kubernetes workloads built for DevOps and DevSecOps teams appeared first on DevOps Online North America.

To challenge and question if what we are doing is the best way to do it is no bad thing when we are ever striving to do less with more. Personally, I also find it adds far more value if you understand why you are embarking on whatever plans you have before looking at how you are going to do it. Then determine what it is you want to do. Now I’m not claiming to have discovered a magic formula and I’d imagine some of you might recall the teachings of Simon Sinek’s and recognise Why, How & What as the layers of the Golden Circle but it is a really simple way to evaluate and assess the things you are doing and if you should continue or change your tact. It’s also key to remember that whatever you do the people involved will either make or break it.

Getting back to the point, Continuous Delivery is a term that seems to mean various different things depending on where your specialism lies. For me, I use the definition from Jez Humble and David Farley’s book “Continuous Delivery”: 

“the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.”

I like this definition for a number of reasons but primarily I like that there is no reference to timings or technology. It is also derived from the first Agile Principle:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”

Again, there is no mention of how frequently this should happen or how you do it only that customer satisfaction is important. One thing we cannot get away from though is that by its very definition Continuous Delivery is directly linked to Agile and its methodologies.

“Different stages of a journey”

As a term, I find that Continuous Delivery is often used interchangeably with Continuous Integration and Continuous Deployment. But to me, they are different stages of a journey. You need Continuous Integration to be able to Continuously Deliver and when you’re there you can progress to Continuously Deploying. Understanding this is key as the journey should focus on improving what you are doing and the quality with a view of simply getting better. The only benchmark you should focus on is the one you set and try to avoid making comparisons with some of the so-called “unicorn” companies that might be deploying 100 times a week.

So why bother starting on this journey? Well, there are some significant benefits to doing so. The key three, in my humble opinion, are:

Lower risk to live releases – This starts to open real confidence benefits. If you are consistently delivering without issue then you’ll quickly find yourself in a good place.

Improved speed to market – Ah the possibilities! Some pretty big players in the software delivery world have made a business out of getting things in front of customers quickly. The quicker you can mobilise the quicker your chances of hitting those market gaps before your competitors.

Higher quality of delivery – Lower risks, better outputs all coupled with the above. Quicker feedback and a product improving rapidly again lend itself to being in a really strong position.

However, it is really important to first determine whether or not this is right for your organisation and your customers. If it isn’t then is the investment worth it?

Highlighting unexpected points

Embarking on a never-ending search to “be” an organisation that “continuously delivers” can highlight some things that you may not have expected initially and it’s important to be wary of those. Forewarned is forearmed after all! You’ll need to be conscious that this isn’t a magic bullet, doing things quicker and more frequently will not fix all of your problems. In fact, it’s very likely to highlight some areas as being a bit worse than you expected. I like to look at it as a giant spotlight you shine on every aspect of your delivery cycle. Whether you want people to see it or not you’re going to. All you are really striving for is a constant commitment to discipline and build on that time after time again. Remain focused on your why and persevere even when it feels tough. The more you do something the better you get at it. But you only achieve this by constantly evaluating what you are doing and how it went then applying these findings the next time around. People are key and you have to create an environment that people feel comfortable being honest in.

Going back to the “why bother?” I started a couple of paragraphs ago though if you’re noticing some of the things listed below then you’re probably in a position that would benefit from a shakeup anyway, so why not do it in a way that encourages some elements of continuous delivery:

Large unmanaged (or lightly managed) “change queues”

Implementation of change requires 6-12 month projects

Smaller changes pooled together as “projects”

Distinct handovers between teams (dev, test, UAT, etc)

Complex release plans

Operational frustration at “slow IT” – lack of trust

Disconnect between technical & operational

In my own experience, I’ve seen them all and ultimately, they have been improved by collaboratively adapting and changing ways of working. Sometimes you can do this with just individual teams or departments but the likelihood is your looking a real cultural shift spanning both top-down and bottom-up changes.

Why Continuous Delivery?

What originally inspired me to talk about this subject came down to working with a single organisation that had simply hit a point whereby it was going to struggle to do the right thing for its clients, usually some of the most vulnerable people in society, and the people involved knew something had to be done but struggled to find a solution. The changes made, looking back, were significant but very gradual and subtle although they felt pretty quick to implement to most. There was a lot of background work to make it seem that way. I’m also talking about an organisation that had previously failed to implement Agile principles so there was a careful managing of ideology required. From this I’ve learned that it’s important to pick your battles and also pick your proving ground. Look at low-risk business areas to thoroughly test, iterate and improve your methods. Do this until you’re comfortable and can show real business benefit. You want to be in a position that almost makes it seem too simple to be true. Bring your business colleagues into the mix and engage them early. This process is as much about engagement and communications as it is anything else. Be prepared to coach, support and promote what you are doing and the people involved. Live it and breath it with them this isn’t a process to be managed from afar.

Once you have a framework and your methodology defined against your why then look to formulate a structure that delivers what you need. This can be anything so long as it works! If it doesn’t work then change it based on the recommendations and suggestions of those involved.  Once you’ve started to get a bit of consistency build-up and scale based on your ambition.

This isn’t all straightforward though and you really do need to expect some negative outcomes, at least initially, and if you’re expecting them then you can avoid the knee jerk reaction of falling back to whatever process or ideology that wasn’t working before – usually because it’s comfortable and, to be honest, usually because those pushing it aren’t accountable! Expect a slow start and improvements to come gradually, you may even go backwards first but stay the course and trust the people.

Taking a deeper look

Now…. When talking about this and actually saying these words out loud one thing really resonated, and this goes back to the definition of continuous delivery I started out with, a lot of what I mentioned can be covered off with implementing some form of Agile. What I discovered was that this often fell a bit short and stopped at the point when a sprint ended and a “delivery” team handed over, what is known in the trade, as a shippable increment. A handoff lends itself to just ticking boxes and not focusing on the reason why you are working in this style. Looking back to the most recent occasion of applying this to an organisation I found that there were issues in quite a few areas that just reinforced a mentality of handing over something so it was someone else’s problem. To combat that we looked holistically at the entire delivery pipeline and actually re-engineered the environments model, team structures, release strategy, and delivery cycles. In that particular organisation it was also necessary to implement an overarching function whose responsibility was to effectively keep the cogs turning, planning, coaching and maintain the standards that underpinned this methodology. This goes back to one of my earlier points of ensuring what you are doing is right for where you are and not blindly following a methodology for the sake of it.

Whilst this wasn’t a quick process and could be likened to the turning of freight ship it was hugely beneficial to do. By improving the standards and the processes around delivery and actually creating a repeatable, scalable framework it also lay the foundations to really kick start some grander ambitions. At the point of starting on this journey the organisation I was helping was delivering around five or six large big-bang projects per year (sometimes more sometimes less) with a huge resourcing overhead and nervousness around releasing to live. After the move to a model that supports continuous delivery, the number of live releases dramatically increased, in the first 6 months of the year well over a hundred live releases had happened, with little to no impact on operational systems. The right people in the right place doing the right things for the right reasons (did I say right enough?!). Not only that the increase in speed with no loss in quality, in fact, but quality also improved, putting it simply – by doing more we had more feedback to act on and by acting on it we had better engagement and ultimately better products.

If you are just beginning on embarking on this journey then I wish you luck. If you’re midway through your journey then I hope it’s going well. But if you’ve finished your journey and are now a “continuous delivery” organisation, are you sure?

On a personal note, I’d love you to hear about your experience and what you’re doing, how it’s going, the challenges you’ve hit and overcome. So, feel free to get in touch.

Yours Continuously Delivering,

Rob Devany, Squad Lead AND Biker at AND Digital

The post Continuous Delivery in the real world appeared first on DevOps Online North America.

Moogsoft, a pioneer and leading provider of artificial intelligence for IT Operations (AIOps), announced today at its annual user conference the launch of Moogsoft Express, a new AIOps Cloud offering with native observability capabilities that helps DevOps and site reliability engineering (SRE) teams deliver continuous service assurance throughout the continuous integration/continuous delivery cycle.

Similar to its flagship offering, Moogsoft Enterprise, Moogsoft Express is built on Moogsoft’s industry-leading AIOps platform. This SaaS solution features intelligent noise-reduction, alert correlation, and native observability capabilities, including metrics collection and anomaly detection. It also offers out-of-the-box workflows and integrations with notification and alerting tools, helping DevOps teams resolve incidents quicker and meet service level agreements (SLAs) with their customers.

Available now in beta, organizations can sign up at https://www.moogsoft.com/aiops-express.

An industry-led AIOps platform

“With the rise of DevOps and the continuous movement of applications to the cloud, SRE teams are struggling with siloed monitoring tools that don’t connect together well and don’t help them detect incidents that could impact the availability and reliability of their applications,” said Phil Tee, CEO of Moogsoft. “With Moogsoft Express, we give everyone access to our industry-leading AIOps platform so they can correlate events, metrics and logs from cloud environments and get visibility into all activity via one unified view. This will help SRE teams detect incidents faster, meet SLAs, and thrive in their DevOps journey.”

“As DevOps teams embrace new technologies, they often suffer from a lack of visibility into operations that makes it difficult to address performance problems when they occur,” said Nancy Gohring, senior analyst at 451 Research. “To solve this challenge they need easy-to-use tools that collect data across their complex, dynamic application environments and quickly extract intelligence to enable the repair of performance issues before they impact end users.”

Moogsoft Express is ideal for DevOps teams and SREs dealing with the operational complexity that results from innovations such as serverless computing, containers, IoT and microservices. Agile, continuous delivery of new software and services requires an AIOps solution that unifies incident, fault, metric and log data, and offers full correlation and visibility across all of them. It is also ideal for customers that will be building out their monitoring tools and infrastructure, actively seeking a unified monitoring solution across many systems and applications. Moogsoft Express easily integrates out-of-the-box with many popular DevOps tools, such as AWS Cloudwatch, Slack and PagerDuty.

Moogsoft Express has been designed to address common challenges such as alert overload, cloud application monitoring, infrastructure monitoring, and DevOps toolchain monitoring.

Included features

Moogsoft Express has an extensive feature set, including:

• A deployable Collector which performs real-time analysis at the source of metric data, and simple APIs to ingest metrics, events, and alerts from monitoring tools such as AWS Cloudwatch, and from systems such as Linux servers and Kubernetes clusters
• Automated application of statistical calculations and noise-reduction algorithms applied to the metric data, making Moogsoft Express a true observability solution that can detect anomalies using learned adaptive thresholds
• Automated analysis of anomalies and events to filter out irrelevant events and data, resulting in contextually relevant alerts
• Robust correlation algorithms enabling like-for-like correlation across all alert types,  resulting in meaningful and actionable incidents
• An enriched incident view, with contextual information and visual charts, providing comprehensive insights into all infrastructure and applications
• Powerful AIOps capabilities grounded in the more than 50 patented AI and machine learning algorithms that Moogsoft has developed since its founding

• Flexible licensing, so your deployment can easily grow with your business as its needs expand to require advanced collaboration, customization, and other enterprise capabilities

Moogsoft showcased Moogsoft Express and the launch of its open beta program at the annual Moogsoft User Conference, which was held in Chicago on October 29-30. For more details, visit: https://muc.moogsoft.com.

Availability of Moogsoft Express Beta: SRE teams and DevOps organizations can sign up for the free beta at https://www.moogsoft.com/aiops-express. Beta customers will receive full service and support during the beta period.

The post Moogsoft Express Launches as an All-in-One AIOps and Observability Solution appeared first on DevOps Online North America.