DEV Community: Samson

Adding JIRA Integration to Policy Reporter for Kyverno

Samson — Sun, 13 Apr 2025 21:13:44 +0000

Introduction

In Kyverno policy management, detecting policy violations is only half the battle. Acting on them efficiently is equally important. Today, I'm excited to share how we implemented JIRA integration in Policy Reporter, allowing Kyverno policy violations to be automatically converted into actionable JIRA tickets.

The Feature

The JIRA integration enables Policy Reporter to:
Create JIRA issues from Kyverno policy violations detected in

PolicyReports

Format violations with detailed information including severity, resources affected, and remediation steps
Customize issue types, fields, and project keys
Filter violations by severity

Implementation Approach

Our implementation focused on three key areas:

1. Configuration Structure

We added JIRA configuration options to Policy Reporter's config structure:

target:
  jira:
    enabled: true
    host: "https://your-instance.atlassian.net/"
    username: "your-email@example.com"
    apiToken: "your-jira-api-token"
    projectKey: "PRJ"
    issueType: "Task"  # Default if not specified

2. JIRA Client Implementation

We created a specialized client to handle JIRA API interactions:

package jira

import (
    "bytes"
    "encoding/json"
    "fmt"
    "net/http"
    "strings"

    "github.com/kyverno/policy-reporter/pkg/crd/api/policyreport/v1alpha2"
)

// Client for Jira REST API interactions
type Client struct {
    host       string
    username   string
    apiToken   string
    projectKey string
    issueType  string
    // other fields
}

// Send creates a JIRA issue from a policy violation
func (e *Client) Send(result v1alpha2.PolicyReportResult) {
    // Transform policy result into JIRA issue
    // POST to JIRA API
}

3. HTTP Request Handling

The most challenging part was correctly formatting the HTTP request to JIRA:

// Create JSON payload
jsonBody, err := json.Marshal(issueData)
if err != nil {
    return
}

// Create HTTP request
req, err := http.NewRequest("POST", fmt.Sprintf("%s/rest/api/2/issue", strings.TrimRight(e.host, "/")), bytes.NewBuffer(jsonBody))
if err != nil {
    return
}

// JIRA API requires Content-Type to be exactly "application/json" (without charset)
req.Header.Set("Content-Type", "application/json")
req.Header.Set("User-Agent", "Policy-Reporter")

// Set authentication
req.SetBasicAuth(e.username, e.apiToken)

Challenges and Solutions

1. JIRA API Quirks

JIRA's API is particular about request formatting. We encountered several issues:
Content-Type header: JIRA requires exactly "application/json" without charset parameters
URL formatting: Double slashes in URLs caused failures
Issue type compatibility: Different JIRA instances have different
available issue types

2. Testing in Kubernetes

Testing the integration locally was straightforward, but testing on Kubernetes presented challenges:
Image building: Making sure the Docker image contained the binary at the correct path

Configuration mapping: Properly passing JIRA credentials to the container
Debugging: Using logs to diagnose API interaction issues

Testing Locally

To test the JIRA integration with Kyverno:

1. Build the binary:

   make build

2. Create a test config (config.yaml):

   target:
     jira:
       enabled: true
       host: "https://your-instance.atlassian.net/"
       username: "your-email@example.com"
       apiToken: "your-jira-api-token"
       projectKey: "PRJ"
       issueType: "Task"

3. Run locally

   ./build/policyreporter run --config config.yaml

4. Create a test Kyverno PolicyReport:

   kubectl apply -f - <<EOF
   apiVersion: wgpolicyk8s.io/v1alpha2
   kind: PolicyReport
   metadata:
     name: jira-test-$(date +%s)
     namespace: default
   results:
   - category: Security
     message: "Test JIRA integration"
     policy: "test-policy"
     result: fail
     rule: "test-rule"
     severity: high
     source: kyverno
     timestamp:
       nanos: 0
       seconds: $(date +%s)
     resources:
       - apiVersion: v1
         kind: Pod
         name: test-pod
         namespace: default
   summary:
     error: 0
     fail: 1
     pass: 0
     skip: 0
     warn: 0
   EOF

Best Practices

Through this implementation, we learned several best practices:

Direct HTTP Requests:

For complex APIs like JIRA, create HTTP requests directly rather than using utility functions, giving you precise control over headers and formatting.

Debug Logging:

Add detailed debug logging during development to understand exactly what's being sent and received.

URL Sanitization:

Always sanitize URLs before constructing requests, especially for trailing slashes.

Content-Type Headers:

Be precise with Content-Type headers, as some APIs are very particular about them.

Error Handling:

Provide detailed error information that includes both HTTP status codes and response bodies.

Conclusion

The JIRA integration for Policy Reporter bridges the gap between Kyverno policy violations and issue tracking, enabling teams to:

Automatically track Kyverno violations in their existing workflow
Ensure compliance issues don't fall through the cracks
Assign and prioritize remediation work

By connecting Kyverno policy management with team issue tracking, we enable smoother compliance workflows and better security governance in your Kyverno-protected clusters.

QUIC Protocol: Revolutionizing Web Communications with OpenSSL 3.5

Samson — Wed, 02 Apr 2025 07:17:52 +0000

Introduction

In today's digital landscape, the speed and security of web communications are more crucial than ever. Enter QUIC (Quick UDP Internet Connections) - a transformative transport protocol initially developed by Google and now standardized as RFC 9000.

While QUIC has been powering much of Google's traffic since 2013, its integration into mainstream development tools like OpenSSL is relatively recent. With OpenSSL 3.2 introducing client-side QUIC support and version 3.5 adding server-side capabilities, developers now have powerful tools to implement this next-generation protocol.

As a recent contributor to OpenSSL's QUIC documentation, I've had the opportunity to explore this protocol in depth. In this post, I'll share what I've learned about QUIC, why it matters, and how you can start using it with OpenSSL.

What is QUIC and Why Does it Matter?

QUIC is a transport layer protocol designed to improve performance, security, and flexibility compared to traditional TCP+TLS combinations. It runs on UDP rather than TCP, allowing it to overcome several fundamental limitations of older protocols.

Key characteristics of QUIC include:

Combined transport and security: Unlike the traditional model where TLS runs on top of TCP, QUIC integrates security into the transport layer itself
Connection migration: QUIC connections can survive network changes (like switching from WiFi to cellular)
Reduced latency: QUIC's 0-RTT (zero round trip time) handshakes allow returning clients to send data immediately
Stream multiplexing: Multiple streams share a connection without head-of-line blocking
Always encrypted: QUIC mandates encryption by design, with no cleartext option

QUIC vs TCP+TLS: Technical Advantages

To understand QUIC's significance, let's compare it with the traditional TCP+TLS approach:

Feature	TCP+TLS	QUIC
Initial Connection	3-way TCP handshake + TLS handshake (2-3 RTTs)	1 RTT for new connections, 0 RTT for returning clients
Head-of-line blocking	Yes, a single lost packet blocks all data	No, independent streams continue despite packet loss
Connection identification	IP address + port	Connection ID (survives IP changes)
Protocol evolution	Difficult due to middlebox ossification	Easier through encryption of transport parameters
Security	Added as a separate layer	Built-in by design
Congestion control	In TCP layer	Integrated and more adaptable

These differences may seem technical, but they translate to real-world benefits: faster page loads, improved mobile experiences, and better performance on unreliable networks.

OpenSSL's QUIC Implementation

OpenSSL, the widely-used cryptographic library powering much of the internet's security infrastructure, began implementing QUIC in version 3.2.0 (released late 2023) with client-side support. The recent 3.5.0 release expanded this to include server-side capabilities.

Key aspects of OpenSSL's QUIC implementation:

Compliance: Follows RFC 9000 standards for interoperability
Integration: Works alongside existing OpenSSL APIs
Performance: Designed with efficiency in mind
API design: New APIs that maintain OpenSSL's familiar patterns

The implementation is still evolving, with ongoing work to enhance features and performance. As a contributor to the project's documentation, I've seen firsthand the care taken to make this complex protocol accessible to developers.

Getting Started with QUIC in OpenSSL

If you're interested in experimenting with QUIC, OpenSSL provides both client and server implementations. Here's how to get started:

Client-side QUIC with OpenSSL

The s_client utility supports QUIC connections through the -quic flag:

$ openssl s_client -connect example.com:443

Known QUIC-supporting sites: Instead of example.com, we should use websites known to support QUIC/HTTP3, such as:

$ openssl s_client -alpn h3 -connect cloudflare-quic.com:443

Server-side QUIC with OpenSSL

Unlike traditional TLS connections, QUIC server functionality isn't available in the standard s_server utility. Instead, OpenSSL provides a dedicated example implementation:

$ ./demos/quic/server/server 4433 server.pem server.key

This server example demonstrates how QUIC connections are established and managed. For production use, you'll want to integrate the OpenSSL QUIC APIs into your application code.

Challenges and Considerations

Despite its advantages, QUIC adoption comes with challenges:

Deployment complexity: QUIC's UDP foundation requires different operational considerations than TCP
Debugging difficulty: Encrypted transport parameters make troubleshooting more complex
Load balancer compatibility: Some load balancers aren't designed to handle QUIC traffic
CPU usage: QUIC can be more CPU-intensive than TCP+TLS due to its encryption overhead

These challenges aren't insurmountable, but they require careful planning when implementing QUIC in production environments.

The Future of QUIC and Web Communications

QUIC represents more than just a performance improvement—it's a fundamental shift in how the web works. With HTTP/3 built on QUIC, we're seeing the next evolution of the web's foundation taking shape.

What's on the horizon:

Broader adoption: As more tools like OpenSSL support QUIC, expect wider implementation
Enhanced features: The QUIC working group continues to refine and expand the protocol
New application patterns: QUIC's unique capabilities will enable novel application architectures
Performance metrics: New ways to measure and optimize web performance in a QUIC-dominated landscape

The integration of QUIC into OpenSSL marks an important milestone in this journey, making advanced transport security accessible to millions of developers worldwide.

Conclusion

QUIC represents a significant leap forward in web transport technology, addressing fundamental limitations of TCP+TLS while introducing powerful new capabilities. With OpenSSL's implementation now supporting both client and server functionality, developers have a robust, open-source toolkit for building applications that leverage QUIC's advantages.

Whether you're building web applications, APIs, streaming services, or IoT platforms, understanding QUIC is becoming increasingly important. As a recent contributor to OpenSSL's QUIC documentation, I've gained appreciation for both the technical sophistication of the protocol and its practical benefits.

I encourage you to experiment with OpenSSL's QUIC capabilities and consider how this next-generation protocol might enhance your own applications. The future of web communications is here—and it speaks QUIC.

Unveiling the Power of Small Open Source Contributions: A Journey in Fixing Quotes in Cilium Documentation

Samson — Thu, 27 Mar 2025 12:23:35 +0000

Introduction

When I first considered contributing to open source, I imagined making significant code contributions that would transform projects. However, my journey began with something seemingly minor: fixing quote marks in documentation. What started as a small documentation fix for the Cilium project taught me that even the smallest contributions can have a meaningful impact on both the project and the contributor.

The Quote Problem That Caused Real Issues

Recently, I noticed an issue with Cilium's documentation for CiliumNodeConfig objects. The documentation showed:

kube-proxy-replacement-healthz-bind-address: "0.0.0.0:10256"

This looked innocuous, but users were encountering errors when copying this exact configuration. The issue? In YAML, colons are special characters that separate keys from values. The string "0.0.0.0:10256" contains a colon that needed special handling through nested quotes:

kube-proxy-replacement-healthz-bind-address: "'0.0.0.0:10256'"

Similarly, a shell command example used double quotes where single quotes would be more appropriate:

# Before
cilium config set --restart=false kube-proxy-replacement-healthz-bind-address "0.0.0.0:10256"

# After
cilium config set --restart=false kube-proxy-replacement-healthz-bind-address '0.0.0.0:10256'

Why this Small Fix Matters?

This may seem trivial, but consider the consequences:
User Frustration: Users following the documentation exactly were encountering validation errors.

Wasted Time: Engineers worldwide likely spent hours debugging this issue.
Support Burden: The Cilium team had to field questions about a problem that shouldn't exist.
Accessibility: Documentation issues create barriers for new users adopting technology.

A simple quote fix addressed all these problems.

What I Learned from This Contribution

Technical Lessons

YAML Parsing Complexity: I discovered how YAML values are processed at multiple levels in Kubernetes objects.
Shell Quoting Practices: I learned why single quotes are safer for shell commands with special characters.
Git Workflow: I practiced rebasing, commit message writing, and responding to reviewer feedback.

Soft Skills developed

Attention to Detail: Finding documentation issues requires careful reading and testing.
Technical Communication: Explaining technical issues clearly in PR descriptions and commit messages.
Receiving Feedback: Responding constructively to reviewer questions.

Why Documentation Contributions Are Valuable

Documentation contributions are often undervalued, but they're critical for several reasons:

Low Barrier to Entry: Documentation fixes are an accessible way to start contributing.
High Impact-to-Effort Ratio: A small fix can help thousands of users.
Knowledge Building: Working on documentation deepens your understanding of the project.
Community Building: Documentation improvements make projects more welcoming.

The Broader Impact

Every time someone uses the corrected documentation and successfully creates a CiliumNodeConfig without errors, time is saved, frustration is avoided, and the technology becomes more accessible. These benefits compound across the entire user base.

Small contributions create a flywheel effect:
Better docs → More users → More contributions → Even better docs

Conclusion

My small quote-fixing contribution taught me that in open source, no contribution is truly minor if it improves the user experience. Whether you're fixing a typo, clarifying an example, or completely rewriting a section, documentation improvements matter.

I encourage anyone looking to start their open source journey to consider documentation fixes as a valuable entry point. The impact of your contribution may be far greater than you imagine.

*About the author: I'm a Staff Software Engineer exploring the open source ecosystem and making my first contributions to projects like Cilium. This experience with fixing documentation quotes was part of my journey to becoming an active open source contributor.

This blog post is based on my experience contributing to Cilium, an open source project that provides networking, security, and observability for cloud native environments.