CloudKnox Security extended support for serverless functions on Amazon Web Services (AWS), Azure, and Google Cloud Platform (GCP). The enhancement adds serverless functions to a substantial list of permissions management capabilities, including users, bots, service accounts, access keys, and other resources.

The company also announced an integration with ServiceNow, the next step of many towards realizing CloudKnox’s next gen cloud security and permissions management vision.

Together, the support for serverless functions and ServiceNow integration underscore CloudKnox’s market lead with the most comprehensive support offering in the cloud infrastructure entitlement management (CIEM) segment.

With this extension, CloudKnox customers gain remediation for multi-cloud serverless functions, allowing security and infrastructure teams to generate a right-sized permissions policy based on activity of roles associated with the serverless function.

In a recent assessment within CloudKnox’s customer base, the company discovered that by categorizing serverless function as non-human identities, the ratio of human to non-human identities jumped from 1 in 5 to 1 in 10.

Given the industry shift from cloud native architecture to microservices, this ratio is expected to continue growing and has led to a need for a holistic permissions management platform. As such, it is critical that organizations take proactive control over managing resources and identities permissions.

“The ephemeral nature of serverless functions leads people to believe that over provisioning for serverless functions is harmless. But the reality is that serverless functions are full-fledged machine—non-human—identities, meaning they can access your infrastructure in the same way a human user can,” said Raj Mallempati, Chief Operating Officer, CloudKnox.

“If a serverless function is over-permissioned, it can cause the same costly damage—either accidentally or maliciously—to an enterprise’s infrastructure that a human user can. As with all identities, serverless functions must be monitored and right-sized when necessary.”

To manage the exponential increase in identities, many companies use information technology service management (ITSM) tools for permissions management and security incident tracking. By integrating with ITSM tools, such as ServiceNow, CloudKnox makes permission automation and permissions on demand possible.

Rather than granting always-on “standing permissions,” organizations can enable access to permissions and resources that are needed for specific tasks for a predefined time, at which point the permissions are rescinded automatically. Plus, by prioritizing such integrations, CloudKnox can fit into any customer’s existing technology ecosystem—no matter the tools they have deployed.

“We’re working with our customers and partners to mitigate the risk of permissions abuse by eliminating the permissions or entitlements gap, thereby preventing unauthorized access to sensitive data,” said Mallempati.

“We take pride in assisting our clients with the monumental challenge of securing their hybrid and multi-cloud infrastructures by identifying their Cloud Permissions Gap risk and successfully implementing the principle of least privilege (PoLP) and Zero Trust access to address it.”

As CloudKnox continues to maintain their industry-leading market position, the company will be introducing more product features in the coming months, including support for container workloads on Kubernetes.

The Cloud Permissions Management Platform was recently named among CRN’s Top 10 Hottest Cloud Startups of 2020 and offers a free Cloud Identity Risk Assessment to help enterprises understand their cloud identity and resource risk profile.

What Is Google Cloud Dataflow?

Google Cloud Dataflow is a fully managed service for executing Apache Beam pipelines on Google Cloud Platform (GCP). It handles provisioning, scaling, and operational management of distributed data processing jobs, supporting both batch and streaming workloads. Developers write pipelines using the Apache Beam SDKs — available in Java, Python, and Go — and Dataflow executes them at scale.

What Is Runner V2?

In mid-2020, Google announced Runner V2, a redesigned version of the Dataflow runner for Apache Beam. The core motivation was to move toward a more services-based, portable architecture that could support all of Dataflow’s language SDKs consistently — rather than maintaining separate, language-specific execution paths that diverged in capability over time.

Runner V2 is built on top of Apache Beam’s portability framework, an initiative within the Apache Beam project to enable pipelines written in any supported SDK to run on any compliant runner without SDK-specific runner code. Google packaged this framework together with two existing Dataflow services:

• Dataflow Shuffle — for optimizing batch job execution
• Streaming Engine — for offloading streaming job state management from worker VMs

By combining these components under the portability framework, Google can now deliver a consistent feature set across all language SDKs, share bug fixes, and roll out performance improvements uniformly.

Key Features of Runner V2

Multi-Language Pipeline Support

Perhaps the most significant capability introduced in Runner V2 is multi-language pipeline support. Prior to this release, a Beam pipeline written in Python could not natively call a transform or I/O connector written in Java, and vice versa. Runner V2 changes this by using the portability framework’s cross-language framework, which allows transforms from one SDK to be embedded in a pipeline written in another.

In practice, this means engineering teams can build reusable pipeline components in their preferred language — say, a high-performance Java I/O connector — and expose those components to teams writing pipelines in Python or Go. The result is a single, high-performance, distributed processing pipeline that spans language boundaries without sacrificing performance or correctness.

Increased SDK Parity

Historically, Beam’s Java SDK was the most feature-complete. Runner V2 significantly narrows the gap between SDKs by delivering:

• State and timer support in Python — enabling stateful processing patterns (e.g., sessionization, aggregation with custom windowing) that were previously only reliable in Java
• More I/O connectors for Python via the cross-language framework, including Kafka I/O — allowing Python pipelines to read from and write to Apache Kafka using the mature Java Kafka I/O implementation

Portable, C++-Based Worker Architecture

Runner V2 introduces a more efficient and portable worker architecture, with critical components rewritten in C++. The worker Virtual Machines (VMs) run the complete pipeline and provide access to the various language SDKs via the portability framework’s gRPC-based worker API. This design separates the runner logic from the SDK-specific user code, making it possible to support new languages without rewriting runner internals.

Custom Container Support

Runner V2 adds support for custom containers. Teams can supply their own Docker container images for the Beam SDK worker environment. This is particularly valuable when pipelines depend on native libraries, non-standard Python packages, or specific OS-level dependencies that cannot be satisfied through standard Dataflow worker images alone.

Increased Throughput via SplittableDoFns

SplittableDoFns (SDF) is an Apache Beam API that allows a single DoFn (a fundamental processing unit in Beam) to be split and processed in parallel across multiple workers. Runner V2 improves the execution of SplittableDoFns, enabling better parallelism for I/O-bound operations such as reading from large files, databases, or message queues. This translates directly to higher throughput for pipelines that use SDF-based I/O sources.

Architecture Overview

The high-level architecture of Runner V2 centers on the worker VM. Each worker VM:

• Runs the portable Dataflow runner (C++-based harness)
• Communicates with language-specific SDK worker containers via gRPC
• Offloads shuffle state (for batch) to Dataflow Shuffle and streaming state to Streaming Engine
• Executes user-defined transforms inside isolated SDK environments, including custom containers

This separation of the runner harness from SDK worker code is the architectural shift that makes multi-language pipelines possible. The runner does not need to understand the semantics of user code; it simply coordinates execution by sending and receiving data via a well-defined portable API.

Why This Matters for DevOps and Data Engineering Teams

For teams running production data pipelines on GCP, Runner V2 offers several practical benefits:

• Reduced maintenance overhead — bug fixes and performance improvements are applied across all SDKs simultaneously, rather than being ported language by language.
• Greater code reuse — high-quality connectors or transforms written in Java can be used in Python pipelines without rewriting them.
• Dependency flexibility — custom container support makes it easier to manage complex dependency trees in containerized CI/CD workflows.
• Future-proofing — as Apache Beam adds new language SDKs (e.g., Go, Typescript), they will benefit from the portability framework from the start, rather than requiring bespoke runner integration work.

Getting Started with Runner V2

Runner V2 can be enabled on existing Dataflow jobs by passing the --experiments=use_runner_v2 flag when submitting a pipeline. Consult the official Cloud Dataflow documentation for the latest guidance on enabling Runner V2, supported regions, and any feature-specific prerequisites such as Streaming Engine or Dataflow Shuffle enablement.

Teams evaluating Runner V2 for production workloads should test pipeline behavior carefully, particularly around stateful operations, I/O connectors, and any custom dependencies, before migrating from the default runner.

Overview

Kong Inc. released version 0.8 of Kong for Kubernetes, its Kubernetes Ingress controller built on top of the Kong API Gateway. The release introduces Knative ingress integration, a new cluster-level Custom Resource Definition (CRD), and annotation changes aimed at simplifying configuration. It also includes breaking changes to path-based routing that existing users will need to address.

What Is Kong for Kubernetes?

Kong for Kubernetes is composed of two tightly coupled components:

• A Kubernetes controller that watches Ingress resources and Kubernetes CRDs, translating them into Kong Gateway configuration.
• The Kong Gateway, an open-source API gateway built on NGINX, which handles the actual processing of incoming API traffic.

Most managed Kubernetes clusters on public clouds default to a vendor-provided Ingress controller tied to the vendor’s load balancer infrastructure. Kong for Kubernetes is an alternative that brings full API gateway capabilities into the Ingress layer, with the added benefit of consistent behavior across cloud providers and on-premises deployments via Kubernetes CRDs.

How Kong Differs from NGINX Ingress Controllers

Although Kong Gateway is itself built on NGINX, Kong for Kubernetes is architecturally distinct from both the community nginx-ingress-controller and NGINX Inc.’s commercial controller. According to Reza Shafii, VP of Products at Kong Inc., the key differentiators are the API management features Kong brings to the Ingress layer:

• OIDC-based authentication
• Advanced rate limiting
• Request caching
• Log and metrics streaming to multiple analytics providers simultaneously
• Support for multiple protocols: REST, GraphQL, gRPC, TCP

Shafii also highlighted performance characteristics cited by Kong Inc., including sub-millisecond latency and support for 25,000+ transactions per second, though independent benchmarks should be consulted before relying on these figures in architectural decisions.

For teams already running Kong Gateway outside Kubernetes, this controller provides a unified API management lifecycle across both Kubernetes and non-Kubernetes workloads — a meaningful operational advantage in hybrid environments.

What’s New in Version 0.8

Knative Ingress Support

The headline feature in 0.8 is support for Knative as an Ingress target. Knative is a Kubernetes-native serverless platform that provides higher-level abstractions for container-based workloads. Its default Ingress backend is Istio, with Gloo as a notable alternative.

Shafii explained the motivation for adding Kong as a Knative Ingress option:

What we have learned from our community and customers is that most use cases don’t require the weight of Istio to run serverless workloads. And in fact, the heavy weight of Istio is one of the reasons that prompted us to initiate the Kuma service mesh project. Kong Gateway’s plugin architecture and focus on extensibility helps keep Knative workloads focused solely on business logic.

Reza Shafii, VP of Products, Kong Inc.

For teams running Knative who find Istio’s operational overhead excessive, Kong for Kubernetes 0.8 offers a lighter alternative with the full plugin ecosystem of Kong Gateway available at the Ingress layer.

New Cluster-Level CRD

Version 0.8 introduces a new cluster-scoped Custom Resource Definition. Cluster-level CRDs are not namespaced, meaning they apply across the entire cluster rather than within a specific namespace. This is useful for global configuration that should not be replicated per namespace — for example, cluster-wide plugin settings or global rate limiting policies.

Annotation Updates

Several annotations have been updated or deprecated in this release to reduce configuration complexity. Users upgrading from previous versions should review the official changelog carefully, as some previously used annotations will no longer function as expected.

Breaking Changes: Path-Based Routing

Version 0.8 includes breaking changes to path-based routing behavior. Any existing Ingress resources that rely on path routing should be tested against the new release before upgrading in production. The full list of breaking changes and migration guidance is available in the official changelog.

Using Cloud Load Balancers with Kong

Kong for Kubernetes does not replace cloud load balancers — it complements them. Shafii described the recommended deployment pattern:

Cloud load balancers provide a way to balance traffic across multiple Kong Gateway nodes, and Kong Gateway nodes help manage traffic to multiple services within a cluster. For most users, we recommend the use of load balancers such as those of AWS or GCP to front Kong Gateways. This provides an endpoint inside the virtual private network in the cloud, which can then be exposed to other networks, partner networks, or directly on the internet.

Reza Shafii, VP of Products, Kong Inc.

In practice this means the typical production topology is: cloud load balancer (AWS ELB/ALB, GCP Load Balancer) → Kong Gateway nodes → individual Kubernetes services. This separates concerns cleanly: the cloud LB handles cross-node traffic distribution and TLS termination at the network edge, while Kong handles API policy enforcement inside the cluster.

Observability and Metrics

Kong for Kubernetes exposes metrics at two levels:

• Traffic metrics (per route and per service): HTTP status codes, error rates, throughput, latency, and ingress/egress bandwidth.
• Gateway health metrics: connections served, active connections, shared memory usage, and cache hit ratio.

These metrics can be exported to the following backends:

• Prometheus
• Datadog
• StatsD
• Zipkin
• Jaeger

This level of observability is comparable to what Istio and Gloo offer, making Kong for Kubernetes a viable choice for teams that need distributed tracing and metrics aggregation without adopting a full service mesh.

Upgrade Considerations

• Review the official changelog for the complete list of deprecated annotations and breaking changes before upgrading.
• Test all Ingress resources that use path-based routing in a staging environment first.
• If you use Knative, verify compatibility with the specific Knative version you are running, as Knative’s own Ingress API has evolved across releases.
• Plan for any CRD migration required by the new cluster-level resource introduced in this release.

Summary

Kong for Kubernetes 0.8 is a meaningful release for teams that want full API gateway capabilities — authentication, rate limiting, protocol flexibility, and rich observability — directly at the Kubernetes Ingress layer. The addition of Knative support gives serverless workloads a lighter-weight Ingress alternative to Istio. However, the breaking changes to path routing mean existing deployments require careful testing before upgrading.

Proliferation of hybrid and multi-cloud architectures has resulted in rapid and remarkable technological advances. But it has also introduced monumental, multi-faceted complexities into IT infrastructure management, including:

Managing multiple on-premises, private and public cloud resources
Complicated and lengthy provisioning processes for resource deployment
Continually evolving challenges maintaining visibility into multi-cloud ecosystems
Ongoing concerns around governance, cost control and security
In the face of these challenges, enterprise IT must enable innovation and digital transformation. Whether through self-service and intelligent automation, or through building a base of continuous insights driven by AI, machine learning, and deep learning, adopting these new paradigms has never been more critical. Simultaneously, IT needs to stay operationally vigilant regarding visibility, governance and cost control as organizations accelerate their hybrid cloud growth.

Unfortunately, many IT leaders are struggling to successfully adapt to these challenges. According to ESG’s 2019 Technology Spending Intention Survey, most executives view IT as a drag on — not a driver of — innovation. Specifically, a mere 6 percent consider IT a competitive differentiator, and a full quarter of executives actually see IT as a business inhibitor. In a rapidly changing world of cloud, there has to be a better way.

By adopting these five core principles of IT infrastructure management, IT leaders can become strategic business drivers and better meet end users where they are:

1. Self-service

To prevent bottlenecks, IT must institute a self-service delivery model enabling developers to access resources when they need them. When end users are able to quickly and easily access the resources they need – storage, compute, networking and more – without having to go through IT, organizations can reach a whole new level of agility and productivity.

2. Intelligent automation

Self-service depends on automation – intelligent automation. It must ensure the orchestrated delivery of IT resources — whether that’s infrastructure or advanced services such as IoT, blockchain and developer tools — fit the end user’s role and responsibilities as well as the needs of the business. With intelligent automation, IT teams can build security and cost guardrails into provisioning those resources, covering everything from access privileges to how long provisioned resources remain available in the cloud. The result? Better governance and cost control.

3. Comprehensive visibility

Business and IT leaders don’t need visibility into some of their infrastructure; they need visibility into all of their infrastructure — whether that’s virtual machines on-prem, to private cloud networks, or multi-tier, load balanced applications in AWS, Azure, GCP and others. And they need this visibility consolidated into a single view, the proverbial “single pane of glass.” Unified visibility enables modern IT leaders to always know where and how resources have been deployed, monitoring all usage from a single platform.

4. Modular extensibility

To swiftly adopt new technologies and leverage existing IT investments, modern IT leaders embrace modular, extensible frameworks. You need such frameworks — for example, modular plug-in in the form of scripts, web hooks and email notifications – to support a rapidly evolving array of development tools, paradigms and priorities. For example, the world of hybrid cloud can mean using a mashup of existing tools, whether that’s Terraform for provisioning, Ansible for configuration, Veeam for cloud migration and many more. IT teams need to go beyond the API and leverage extensibility that makes plug-and-play painless. The result? Less vendor-locking and the ability to build your hybrid cloud, your way.

5. Continuous insight

Unified visibility into IT resource deployment and usage depends on the capture of data across workloads, clouds and teams. This allows IT teams to quickly identify areas of risk, sprawl and inefficiency. More impactfully, it also enables IT to pursue data-driven resource planning. With increased accuracy in rate estimation, up-to-date views of inventory and predictive provisioning based on recognized patterns of usage, IT can proactively anticipate the needs of the business and application development teams, becoming the innovation enabler it should be.

Real-world examples: The Home Depot

Situation

The Home Depot had its sights set on continuous integration and continuous delivery (CI/CD), but getting a machine provisioned took anywhere from several days to a week, causing major bottlenecks in business productivity. Also, the company lacked an effective way to track and manage resources, particularly in its hybrid cloud environment.

Solution

The company developed a self-service model, providing developers with front-facing infrastructure services. The IT team now allows thousands of users to provision cloud-based resources without submitting a ticket. What once took one to two weeks now takes 20 minutes.

Furthermore, by implementing a more flexible framework built on modular extensibility for orchestration, Home Depot made integration with existing infrastructure easy. This extensibility supports Home Depot’s evolving IT strategy and facilitates the adoption and integration of Kubernetes, Docker, Terraform and other emerging technologies.

InterContinental Hotels Group (IHG)

Situation

IHG owns over 5,000 hotels and utilizes four different public clouds. They wanted the flexibility of multiple public clouds in order to use the platform that provides the optimal environment for each workload, as well as to protect the organization from price increases and instabilities from any one public cloud. As a result, administrators needed to understand and use four different interfaces to locate, manage and provision compute resources.

Solution

IHG moved all managed resources from VMware vRA to a cloud management platform that provided a single user interface and API, through which they could deploy complex apps to VMware and any of the four public clouds they used. This enabled them to manage these apps and their servers over the course of their lifecycle, allowing for business policy automation as well as adoption of best practices around server deployment and management.

IHG now also uses comprehensive visibility and intelligent automation to control VM sprawl and protect against unexpectedly large bills from vendors. Through the use of expiration dates for servers, configurable expiration behavior, visibility into all VMs across all technologies, quotas, cost tracking and easy de-provisioning of servers and services, IHG ensures that organizations only pay for what they need and use.

The 5 principles and your organization

To tame enterprise IT infrastructure complexity, IT leaders must adopt a flexible and extensible model for IT infrastructure management that relieves pressure on IT while freeing both the enterprise and developer teams to take advantage of emerging technologies. By adopting the five core principles of IT infrastructure management, your organization can improve time-to-value for your hybrid cloud and multi-cloud management strategy.