DEV Community: Atulpriya Sharma

How To Run Static Analysis On Your CI/CD Pipelines Using AI

Atulpriya Sharma — Thu, 17 Oct 2024 07:27:57 +0000

“An inadvertent misconfiguration during a setup left a data field blank, which then triggered the system to automatically delete the account.” - was Google's explanation for accidentally deleting a pension fund's entire account.

Incidents like these highlight the importance of configuration accuracy in modern software systems. A simple misconfiguration can have devastating consequences, particularly in CI/CD pipelines.

Ensuring configuration accuracy and managing the complexity of code reviews can be daunting for DevOps engineers. Teams often prioritize feature development, leaving configuration reviews as an afterthought. This can lead to unnoticed misconfigurations, causing production issues and downtime.

CodeRabbit helps solve this by automating code reviews with AI-driven analysis and real-time feedback. Unlike other tools requiring complex setups, CodeRabbit integrates seamlessly into your pipeline, ensuring that static checks on configuration files are accurate and efficient.

In this blog post, we will look at CodeRabbit and how it helps with static checking in CI/CD Pipelines, ensuring configuration quality and improving efficiency throughout the end-to-end deployment process.

Why Static Checking is Crucial in CI/CD Pipelines

Configuration files are the backbone of CI/CD pipelines that control the deployment of infrastructure and applications. Errors in these files can lead to costly outages and business disruptions, making early validation essential. Static checking is vital in mitigating security vulnerabilities, code quality issues, and operational disruptions.

Below is an example of a Circle CI workflow configuration file that sets up a virtual environment, installs requirement dependencies, and executes linting commands.

jobs:
 lint:
   docker:
    - image: circleci/python:3.9
   steps:
    - checkout
    - run:
        name: Install Dependencies
        command: |
        python -m venv venv
        . venv/bin/activate
        pip install flake8
    - run:
        name: Run Linting
        command: |
        . venv/bin/activate
        flake8 .

If static checking didn’t happen in the above configuration, issues like unrecognized syntax or invalid configurations in the Python code could leak, causing the build to fail at later stages. For example, missing dependencies or improperly formatted code could lead to runtime errors that break deployment pipelines or introduce hard-to-trace bugs in production.

Overall, static checking helps with:

Early error detection: Static check identifies syntax errors and misconfigurations in code before execution, which reduces the likelihood of runtime failures.
Enforce coding standards: This ensures consistent code quality by enforcing style guidelines and best practices across code and configuration files, making it easier to maintain & review changes.
Enhancing Code quality: Static checks help enforce criteria like passing tests or x% of code coverage, which must be met before any deployment, thus improving the overall quality.

Using CodeRabbit For Static Checking

CodeRabbit gives an edge by identifying common misconfigurations by integrating with your CI/CD workflows. This capability is crucial for maintaining the integrity of the deployment process and preventing disruptions that could affect end-users.

In addition, it provides a distinctive benefit in executing static analysis and linting automatically, requiring no additional configuration. For DevOps teams, this functionality streamlines the setup process so they can concentrate on development rather than complicated settings.

It integrates with your CI/CD pipelines without causing any disruption and automatically runs linting and static analysis out of the box, requiring no additional configuration.
It supports integration with a wide range of tools across popular CI/CD platforms like GitHub, CircleCI, and GitLab, running checks such as Actionlint, Yamllint, ShellCheck, CircleCI pipelines, etc. This simplifies setup, providing quick results without additional manual effort.
For tools like Jenkins and GitHub Actions, CodeRabbit continuously runs static analysis on every build or commit, catching misconfigurations early and improving workflow reliability.

Let us look at CodeRabbit in action in the following section.

Detecting Misconfiguration with CodeRabbit and GitHub Actions Actionlint

To demonstrate the functionality of CodeRabbit, let us look at how we integrate a GitHub Actions workflow into a project to automate the CI/CD pipeline. The repository has a configuration file with potential errors, which will be flagged and reported by CodeRabbit.

Below is a diagram of the sequence of tasks in the workflow file we created.

By submitting a pull request, we allowed CodeRabbit to review the file and detect potential misconfigurations automatically. Once the repository is prepared, we integrate it with CodeRabbit to set up automated code reviews and generate a comprehensive, structured report consisting of the following key sections

Summary – A concise overview of the key changes detected in your code or configuration. This helps you quickly understand the main areas that need attention.

Walkthrough – A detailed, step-by-step analysis of the reviewed files, guiding you through specific issues, configurations, and recommendations.

Table of Changes – A table listing all changes in each file and a change summary. This helps you quickly assess and prioritize necessary actions.

You can customize these sections by tweaking the configuration file or using the CodeRabbit dashboard. Refer to our CodeRabbit configuration guide to learn more.

Here a sample workflow.yaml config file, on which detailed insights and recommendations through CodeRabbit's review process.

name: development task

on:
  push:
    branches:
      - main
      - develop
      - staging
  pull_request:
    branches:
      - main
      - develop
      - staging

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Lint workflow YAML files
        uses: rhysd/actionlint@v1

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm install

      - name: Lint JavaScript code
        run: npm run lint

  build:
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies and cache
        uses: actions/cache@v3
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-
        run: npm install

      - name: Run tests
        run: npm test

      - name: Check for vulnerabilities
        run: npm audit --production

  terraform:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: 1.5.0

      - name: Terraform init
        run: terraform init
        working-directory: infrastructure/

      - name: Terraform plan
        run: terraform plan
        working-directory: infrastructure/

      - name: Terraform apply (development)
        if: github.ref == 'refs/heads/develop'
        run: terraform apply -auto-approve
        working-directory: infrastructure/
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCES_KEY: ${{ secrets.AWS_SECRET_ACCES_KEY }}

  docker:
    runs-on: ubuntu-latest
    needs: terraform
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Login to AWS ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1
        with:
          region: us-east-1

      - name: Build and tag Docker image
        run: |
          IMAGE_TAG=${{ github.sha }}
          docker build -t ${{ secrets.ECR_REGISTRY }}/my-app:latest .
          echo "IMAGE_TAG=$IMAGE_TAG" >> $GITHUB_ENV

      - name: Push Docker image to AWS ECR
        run: |
          IMAGE_TAG=${{ env.IMAGE_TAG }}
          docker push ${{ secrets.ECR_REGISTRY }}/my-app:$IMAGE_TAG

  deploy:
    runs-on: ubuntu-latest
    needs: docker
    environment: production
    steps:
      - name: Deploy to Development
        if: github.ref == 'refs/heads/develop'
        run: |
          echo "Deploying to development environment"
          # Your deployment script here

      - name: Deploy to Staging
        if: github.ref == 'refs/heads/staging'
        run: |
          echo "Deploying to staging environment"
          # Your deployment script here

      - name: Manual Approval for Production
        if: github.ref == 'refs/head/main'
        uses: hmarr/auto-approve-action@v2
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}

      - name: Deploy to Production
        if: github.ref == 'refs/heads/main'
          run: |
          echo "Deploying to production environment"
          # Your deployment script here

Before getting into the code review, here’s a high-level overview of what the workflow file accomplishes:

triggers the CI/CD pipeline on pushes and pull requests to the main, develop, and staging branches, ensuring continuous integration.
executes a linting workflow that checks the syntax of the YAML configuration and installs the necessary dependencies for the application to ensure code quality.
sets up Terraform to manage and provision the cloud infrastructure needed for the application.
executes tests to validate the functionality of the application and checks for vulnerabilities, ensuring the code is secure and stable.
builds and tags a Docker image for the application, preparing it for deployment.
pushes the Docker image to AWS Elastic Container Registry (ECR), enabling easy access for deployment.
deploys the application to different environments (development, staging, and production) based on the branch, including a manual approval step for production deployments to ensure control and oversight.

Having examined the workflow.yaml configuration file and its various components, we now delve into the individual section, starting with the summary.

Summary

This summary serves as an essential first step in the review process, offering a clear and concise overview of the changes introduced in the latest commit. It provides a quick understanding of the key aspects covered, including new features, styling adjustments, configuration changes, and other relevant modifications raised in the pull request.

The above snippet highlights important maintenance tasks, including running the application in non-debug mode for improved performance and implementing an automated CI/CD pipeline to streamline code linting, building, and deployment processes.

This summary helps in understanding the key changes and enhancements made in the latest commit.

After reviewing the key changes in the Summary, we can explore the Walkthrough section of the report, which provides a detailed breakdown of specific modifications.

Walkthrough

This section provides a comprehensive overview of the specific modifications made across different files in the latest commit. Each file is assessed for its unique contributions to the project, ensuring clarity on how these changes enhance the overall functionality and user experience.

The Changes Table serves as a concise summary of specific modifications made across various files in the latest commit, allowing developers to quickly identify where changes have occurred within the codebase.

Each row indicates an altered file, accompanied by a detailed description of the modifications in the Change Summary column. This includes updates related to styling in CSS files, application logic functionality adjustments, and CI/CD pipeline configuration enhancements.

By presenting this information in a structured format, the table offers clarity and organization, making it easier for developers to digest and understand the impact of each change on the project.

Overall, It acts as an essential reference for collaboration, enabling team members to focus on pertinent areas that may require further discussion or review while tracking the evolution of the codebase. To add some fun elements, it generates a poem for your errors.

Code Review

The following section thoroughly examines the configuration file, identifying areas for enhancements. From improving caching strategies to optimizing deployment processes, these recommendations are designed specifically to code to enhance your GitHub Actions workflow's overall efficiency and robustness.

It provides details and an overview of the actionable comments about the review details, the configuration used, the review profile, the files selected for processing, and the additional context used. These can also include one-click commit suggestions.

Let us look at the various review comments that CodeRabbit suggested for various sections of the workflow file. It automatically detects that the configuration file is a GitHub Actions workflow and uses actionlint to analyze it thoroughly. During the review, CodeRabbit provides valuable insights and suggestions for optimizing performance.

In our lint job it identified an opportunity to cache npm dependencies using actions/cache@v3. By recommending the addition of a caching step before the linting process it helps reduce execution time for subsequent runs. This proactive feedback streamlines workflows without requiring manual intervention, ensuring a more efficient and optimized CI/CD pipeline.

As it points out, the caching step is incorrectly structured. The run command (npm install) is placed within the uses block of the cache action, which could lead to improper execution.

To resolve this, it suggests separating the caching and installation steps. The corrected version moves the cache logic into its own block and ensures the npm install command is executed independently in the next step, using npm ci for a cleaner, faster installation of dependencies.

In the Terraform section of the configuration, it detects a potential issue using a variable for the Terraform version. Additionally, AWS credentials too would cause an issue, especially in plan and apply steps. Lastly, it detects typos in AWS_SECRET_ACCESS_KEY, as even minor mistakes can cause failures in your pipeline's execution.

It suggests the changes in the configuration that fixes the typos, makes the Terraform version easily updatable, and ensures AWS credentials are available for all Terraform commands.

In the docker job, it detects security vulnerabilities as the image is using the latest tag for the Docker image, which can be problematic for image versioning and rollbacks. It suggests configuration changes that consider both the latest tag and a specific version tag (e.g., git SHA) for better traceability and easier rollbacks.

It also detected several potential issues in the deploy job that need attention. The manual approval step uses an auto-approve action, which defeats its purpose. Further, it finds a syntax error in the production deployment step, and the actual deployment scripts are missing, making the process incomplete. It suggests changes for these potential issues along with the required changes.

CodeRabbit’s AI-powered analysis showed how configuration file issues were quickly identified, highlighted, and suggested changes.

Benefits of Using CodeRabbit in CI/CD Pipelines

By automating code reviews and providing precise feedback, CodeRabbit improves code quality and ensures that potential issues and vulnerabilities in your CI/CD pipeline are caught early, leading to smoother deployments and fewer errors.

Let us look at some of the larger benefits of using CodeRabbit in CI/CD pipelines:

Enhanced Developer Productivity

By performing automated static checking workflows, CodeRabbit reduces the need for manual reviews and enables DevOps engineers to focus on strategic tasks like optimizing infrastructure and deployment processes rather than fixing configuration issues. Its instant feedback loop ensures issues are detected quickly and addressed after every commit, allowing you to maintain a rapid development pace.

Improved Code Quality

CodeRabbit enforces consistent configuration standards by automatically validating configuration files against the best practices and catching configuration errors early. The platform learns from the previous review, intelligently suppresses repetitive alerts and allows you to focus on the most critical issues, making code reviews more efficient without compromising on thoroughness. CodeRabbit can also provide one-click suggestions that you can quickly integrate into your configuration files.

Security

CodeRabbit helps DevOps engineers catch security vulnerabilities early, such as misconfigured access controls or insecure settings, reducing the chance of breaches. By integrating static checks into the CI/CD process, CodeRabbit prevents configuration errors from causing deployment failures, ensuring a more stable and reliable software delivery pipeline.

Conclusion

We saw in this post how misconfigurations can lead to delays, security vulnerabilities, or even broken deployments, making it essential to test them just as rigorously as application code.

Unlike traditional approaches that overlook the criticality of testing configuration files, CodeRabbit helps review CI/CD pipelines by automating code/config reviews, catching critical errors, and enhancing overall code quality. It significantly reduces manual review time, allowing DevOps teams to focus on strategic tasks and accelerate deployment cycles.

Experience the impact of AI code review on your workflows – start your free CodeRabbit trial today.

Treat Your Developers As Customers - Platform Engineering

Atulpriya Sharma — Thu, 22 Feb 2024 06:50:00 +0000

Do you know what's common between apps like Zomato, Uber, Instagram and the likes? 🤔

All these apps are built keeping their customers in mind.

They collect tons of metrics, feedback, and understand usage patterns to decide the roadmap for their apps.
The same analogy can be applied to Platform Engineering as well.

Treat your developers as your customers and their requirements as features of your platform. 😮

Understand what your developers do, from what tools they use to the processes they follow.

These will help you build a customer-focused platform that your developers will like and use. 👨‍💻

More importantly, enable feedback mechanisms that will help your developers pass on critical feedback that will be useful in shaping your platform.

Customer-centricity is just one of the tenets of the Product Mindset for building platforms.

In this blog post, I've listed other tenets as part of the platform as a product mindset that you can incorporate.

Follow me @TheTechmaharaj on Twitter for more updates on platform engineering, DevOps, Kubernetes, and Cloud Native in general.

For Food and Travel content, check out my blog [socialmaharaj.com](https://socialmaharaj.com] or follow @Atulmaharaj on Instagram or @Atulmaharaj on Twitter.

NPCI Releases Falcon: An Open source Hyperledger Fabric Deployment Helper for Kubernetes

Atulpriya Sharma — Wed, 30 Aug 2023 04:42:39 +0000

Hot off the press!

National Payments Corporation Of India (NPCI) just jumped on the #OpenSource bandwagon by releasing Falcon - a Hyperledger Foundation Fabric Deployment Helper for #Kubernetes. It's a huge moment for India, open source & and #blockchain enthusiasts.

Let's understand what Falcon does in this short blog post.

▶ But before that, what is Hyperledger? ⛓️

Hosted by The Linux Foundation - Hyperledger is a hub for various blockchain frameworks, tools, and libraries designed for enterprise use cases. It has a range of projects that focus on creating, deploying, and operating distributed ledgers.

▶ Kubernetes on the other hand comes with a suite of benefits in terms of scaling, high availability, resource management, and orchestration. So anything that runs on Kubernetes can take advantage of it. Hyperledger too can be deployed on Kubernetes, but has its own challenges.

▶ Deploying any blockchain solution on Kubernetes is difficult due to:

1️⃣ Complex Network Setup
2️⃣ Data Persistence
3️⃣ Consensus Mechanisms
4️⃣ Distributed Ledger Scalability

That's where Falcon comes in.

▶ Falcon helps simplify setting up, configuring, and maintaining Fabric nodes, peers, orderers, and channels within a Kubernetes environment. Templatized and customizable helm charts help deploy Hyperledger networks easily.

Current Features:

Chaincode Lifecycle Management
Channel Management
Peer & Order Creation
CA management and more

▶ But wait, is this production ready?

Well, Falcon is utilized across multiple #blockchain projects within NPCI.

While most of us relate NPCI with #UPI, it's great to get a sneak peek into the cutting edge infra power it!

Check out their repo for more details 👉 https://github.com/npci/falcon

PS: They're open for contributions, so go ahead and leave a mark in making a global payment network that's second to none!

NPCI #UPI #Blockchain #Kubernetes #CloudNative #OpenSource #NewsUpdate #Falcon

First Thoughts On Threads By Meta

Atulpriya Sharma — Thu, 06 Jul 2023 10:50:03 +0000

While I was busy un-tangling the different threads at work and life in general, a new thread emerged today morning. If you don't know what I'm talking about, then you probably are living under a rock.

Launched by Meta, Threads is a social media platform with a stark resemblance to Twitter. While Twitter is dealing with its share of problems, Threads is a refreshing take on Twitter with many features work in progress.

And yes, like everyone else, I too searched for Threads on my Instagram app and joined Threads.

A few things that I noticed after using it briefly:

👍 The signup process is one of the simplest among any other platforms - Mastodon, Bluesky etc. Being tightly coupled with Instagram, it takes everything (Profile picture, bio, links, followers etc.) from your Instagram profile to sign you up on Threads. This seamless process makes user onboarding easier, and that's why it has had more than 11 Mn sign-ups within 4 hours of launch!

📱 Currently only a mobile app, Threads is text-only. It does support photos, but no videos or GIFs at the moment.

📝 Creating threads on the Thread app is super-easy, much easier than Twitter. If you've used Typefully on the web, you know this looks very similar to that.

🎉 Ad-free at the moment, with no ads whatsoever on the feed.

🤔 The interesting thing here is, Instagram has creators who mostly create video content nowadays. So how does onboarding them to a text-only platform work? Because their skill is video and not text and currently my feed is full of photos and links to reels.

🤷‍♂️ Maybe creating a Reels app and making Instagram all about photos again, could have been better. Or make Threads a standalone platform without the integration with Instagram.

🚨 PS: You cannot delete your Thread account. If you want to, you need to delete your Instagram account.

PPS: You can follow me on Threads for more non-work content: https://www.threads.net/@atulmaharaj

You can also follow me on my blog at https://socialmaharaj.com

Understanding Authentication & Authorization in Istio

Atulpriya Sharma — Thu, 29 Jun 2023 09:07:24 +0000

Modern organizations are increasingly adopting a distributed approach to application development, harnessing the power of microservices and leveraging Kubernetes for hosting. This paradigm shift offers unparalleled flexibility and scalability, aligning with evolving customer expectations. However, this transformation also introduces security concerns as numerous services interact, necessitating robust measures to safeguard sensitive data.

Enter service mesh, which play a pivotal role in addressing these challenges. Not only do they streamline the management of microservices, relieving developers of operational complexities, but they also offer robust security features. Service mesh handles crucial tasks such as authentication, authorization, and routing, bolstering the security of your application.

In this blog post, we will explore Istio, the service mesh tool we use, and how we leverage its capabilities to implement authentication and authorization policies, bolstering the security of our application."

Overview of security options in Kubernetes

Being one of the most preferred choices for container orchestration tools, Kubernetes provides a suite of security options out of the box. From the widely used Role Based Access Control (RBAC) to Pod Security Admission and Network Policies, Kubernetes does provide a basic level of security.

Network policies allow organizations to define and enforce network-level rules within a cluster using ingress and egress rules. These allow for fine-grained control over the traffic flow between pods, namespaces, and other endpoints. These work at the IP address or port level - OSI Layer 3 or 4 to control the flow of traffic. By default, a pod allows all inbound and outbound connections and these can be controlled by using to and from selectors. Read more about network policies.

Limitations of Kubernetes network policies

While network policies do provide a basic form of security, they lack some vital features that are required for production-grade deployments.

Network Policies in Kubernetes focus on controlling traffic between pods based on IP addresses, ports, and protocols. However, they do not provide a mechanism to force internal cluster traffic to go through a common gateway.
Handling TLS-related tasks, such as SSL termination, certificate management, and encryption, is not a native feature of Network Policies. These do not directly handle TLS-related configurations.

As recommended by Kubernetes, a service mesh emerges as a powerful solution to overcome the above limitations of network policies. It offers advanced traffic routing capabilities along with a comprehensive TLS approach. You can read our blog post on demystifying service mesh to learn more about service meshes.

Let’s see how service meshes differ from Kubernetes network policies.

Advantages of service mesh over Kubernetes network policies

While network policies primarily handle network-level segmentation, a service mesh goes beyond that, offering a more comprehensive solution for managing and securing microservice within a cluster.

Let us examine the differences between a service mesh and Kubernetes network policies.

Feature	Kubernetes Network Policies	Service Mesh
Traffic Management	Basic segmentation based on IP, ports, and protocols	Advanced features like routing, load balancing, service discovery
Observability	Limited or no built-in observability	Advanced observability and metrics
Security	No direct support for TLS	Comprehensive TLS support and encryption
Granularity	Pod-level network control	Fine-grained control over service-to-service traffic
Complexity	Simpler configuration and management	Additional complexity due to additional components (sidecar proxies)
Ecosystem Integration	Specific to Kubernetes ecosystem	Works with any container orchestrator

When it comes to managing microservices communication and securing your Kubernetes environment, a service mesh offers distinct advantages over Kubernetes Network Policies.

Native support for mTLS and JWT authentication: Most of the service meshes provide out-of-the-box support for mutual Transport Layer Security (mTLS) and JSON Web Token (JWT) authentication. This assures secure communication between microservices by encrypting data in transit along with secured authentication mechanisms.
Control and visibility over network traffic: A service mesh offers advanced traffic management capabilities, such as intelligent routing, load balancing, and circuit breaking. It provides fine-grained control over network traffic, allowing you to implement traffic-shaping strategies, and observability features like metrics, logs, and distributed tracing out of the box.
Fine-grained access control through RBAC policies: Service meshes also enable granular access control through Role-Based Access Control (RBAC) policies. You can write and enforce policies that govern which services can communicate with each other, based on specific criteria like service identity, namespace, or labels.

There are different types of service meshes available today and most of them offer these capabilities. In the following section, we’ll shift our focus to Istio and learn about its authentication and authorization options.

Istio - empowering authentication and authorization

Istio is a popular open source service mesh that seamlessly integrates with Kubernetes. It unlocks advanced capabilities ranging from traffic management to observability and security. Istio acts as an infrastructure layer between application services – enabling transparent and intelligent communication between them. Service mesh enhances the control and reliability of your Kubernetes deployments. Its core features include:

Traffic management: Istio enables fine-grained control over traffic routing, load balancing, and fault tolerance through intelligent routing rules. It offers capabilities like weighted routing, circuit breaking, and retries to optimize traffic flow and ensure robustness. One can also use Istio for progressive delivery and automate your application deployments.
Observability: Istio provides comprehensive observability through metrics, distributed tracing, and logging. You can monitor and analyze service-level performance, latency, and error rates to identify and resolve issues effectively.
Security: Istio strengthens the security of your Kubernetes environment by providing secure communication between services through automatic mutual TLS encryption. It also offers features like access control, authentication, and authorization through robust identity and security policies.

These were just a few features of Istio. You can refer to Istio’s documentation for the complete list of features.

Of all these, security is going to be the focus of our discussion going forward. We’ll understand the various options it provides from a security perspective.

mTLS for service-to-service communication: mTLS (mutual Transport Layer Security) is a security mechanism that ensures encrypted and authenticated communication between services. Istio provides native support for mTLS encryption, ensuring secure communication between services within the cluster.
Authorization and authentication with JWT tokens: Istio adds an additional layer of security by utilizing JSON Web Tokens (JWT) for authorization and authentication. Services can verify the authenticity of JWT tokens to grant access based on the claims contained within the token. This helps prevent unauthorized requests and enhances overall security.
Allow/Deny & custom policies: Istio allows the creation of Allow/Deny policies to define which services are allowed or denied communication based on various criteria such as source, destination, and other attributes. Additionally, Istio enables the creation of custom policies to meet specific security requirements, providing granular control over service-to-service communication.

Implementing authentication and authorization policies in Istio

In the preceding sections, we learned about various security features that Istio provides. We’ll now see how to implement these in a microservices-based application deployed on a Kubernetes cluster.

Pre-requisites

Kubernetes cluster - we’re using Minikube for this blog post
Microservices-based application - we’re using the Online Boutique application

Setting up Istio

Setting up Istio on our Kubernetes cluster is fairly simple and the official documentation is perfect for it. At a very high level, there are three things that need to be done:

Download the latest version of Istio & configure istioctl
Install Istio using the demo profile
Enable automatic sidecar injection for the default namespace using kubectl label namespace default istio-injection=enabled

With this, we have configured Istio on our cluster and enabled automatic sidecar injection in the default namespace. Any application we now install to the default namespace will have the sidecar injected automatically.

Deploy online boutique application

The next step is to deploy the Online Boutique application.

Clone the repo

https://github.com/GoogleCloudPlatform/microservices-demo

Deploy the application

kubectl apply -f ./release/kubernetes-manifests.yaml

Verify deployment

kubectl get pods -A

NAMESPACE    NAME                                   READY   STATUS  AGE
default      adservice-5f58d84d94-pjgsk             2/2     Running   2m34s
default      cartservice-58c4f996f5-jssdl           2/2     Running   2m34s
default      checkoutservice-65886cf7fb-mnxhv       2/2     Running   2m34s
default      currencyservice-645c6dd8-rz9pq         2/2     Running   2m34s
default      emailservice-7956996f78-2rtqt          2/2     Running   2m34s
default      frontend-78f8447ffd-fvx7j              2/2     Running   2m34s
default      loadgenerator-5cdd7f7bfc-dcgmg         2/2     Running   2m34s
default      paymentservice-767f89d888-pz7jc        2/2     Running   2m34s
default      productcatalogservice-5dbbcc58b6-fv8xh   2/2   Running   2m34s
default      recommendationservice-f5d756558-dxnwh  2/2     Running   2m34s
default      redis-cart-66fc6f5646-vrfds            2/2     Running   2m34s
default      shippingservice-9c9675994-rdr7v        2/2     Running   2m34s

We can see that the application is deployed successfully. If we observe closely, we see that every pod has 2 containers and that’s because of the automatic sidecar injection that we enabled.

We can also access the application using the URL of the frontend-external service. Type minikube service list and click on the URL against the frontend-external service.

Implementing mTLS

By default all the communication that happens within the cluster is not encrypted i.e.: both TLS and plain text traffic are accepted. We can check that by accessing the frontend service from a pod using a cURL request as shown below:

kubectl exec $(kubectl get pod -l app=productcatalogservice -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'

200

We can see that the response is 200, this means that the service is accessible without any authentication mechanism in place.

We can implement mTLS per service or for the entire namespace. Use the following yaml file to enable strict mTLS for the complete namespace.

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "default"
spec:
  mtls:
    mode: STRICT

Apply this configuration

Kubectl apply -f mtls-ns.yaml

Let’s execute the same that we used earlier to access the frontend service from another pod.

kubectl exec $(kubectl get pod -l app=productcatalogservice -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
000
command terminated with exit code 56

The HTTP Response code is not 200. Instead, the command terminates with exit code 56. This means that the request failed to receive any data and this is because there was no TLS certificate that was passed with the request. If you want to know more, read this thread on istio mTLS proof with tcpdump.

With this, we have enabled strict mTLS for the entire namespace and every request has to be mTLS.

Note: If mTLS is set to strict and your application is exposed using ingress controller, make sure to inject the Istio sidecar inside the Ingress controller as well else It won’t be able to communicate with the application.

Implementing JWT authentication

Istio also provides authentication mechanisms for secured access. We will now enable origin authentication using JWT tokens. We first need to create and apply a policy that will enforce JWT authentication.

But before doing that we need to create a public-private key pair using which we will create JWT token that will be used.

Key generation

Generate public/private keys using the following commands:

$ openssl genrsa -des3 -out private_encrypted.pem 2048
$ openssl rsa -pubout -in private_encrypted.pem -out public.pem
$ openssl rsa -in private_encrypted.pem -out private.pem -outform PEM

There are different ways to generate a token, we’ll use a simple Python script to generate a token for us. All the Python files used here are placed in this repo.

from authlib.jose import jwt

header = {'alg': 'RS256'}
payload = {'iss': 'admin@infracloud.io', 'sub': 'admin', 'exp': 1685505001}
private_key = open('private.pem', 'r').read()
bytes = jwt.encode(header, payload, private_key)
print(bytes.decode('utf-8'))

Here we provide the details like issuer, subject, and expiry time along with the private key. The code will generate a token.

We then need to generate JWK that we’ll pass as a parameter in Istio’s policy configuration yaml. We’ll use another simple Python script to do that:

from authlib.jose import jwk
public_key = open('public.pem', 'r').read()
key = jwk.dumps(public_key, kty='RSA')
print(key)

Pass the public key file that we generated earlier and this will generate the JWK key that is required to create the Istio policy.

Policy creation

We will create a yaml configuration file that will enforce JWT authentication for all incoming requests to the frontend service.

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
 name: frontend
 namespace: default
spec:
  selector:
    matchLabels:
      app: frontend
  jwtRules:
  - forwardOriginalToken: true
    issuer: admin@infracloud.io
    jwks: |
      {"keys": [{"n": "<actual-key>", "e": "AQAB", "kty": "RSA"}]}

Note: Replace <actual-key> with your actual key.

Apply the file to enforce the policy

kubectl apply -f jwt.yaml

Now let us make a request to the frontend by passing the authentication token. We can create a variable named TOKEN and pass it in the cURL request.

kubectl exec $(kubectl get pod -l app=productcatalogservice -o jsonpath={.items..metadata.name}) -c istio-proxy \
-- curl  http://frontend:80/ -o /dev/null --header "Authorization: Bearer $TOKEN" -s -w '%{http_code}\n'
200

Let us remove the token and retry.

kubectl exec $(kubectl get pod -l app=productcatalogservice -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl  http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
403

We get an HTTP 403 - Forbidden response, which validates that our policy is working as expected.

Implementing authorization

Authentication refers to the “who” should be allowed access while Authorization refers to “what” they are allowed to access. For instance, a user request with a valid token can access the frontend service. Let us understand that through a simple example.

Create a new yaml configuration to enable authorization

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: frontend
  action: ALLOW
  rules:
  - when:
    - key: request.auth.claims[iss]
      values: ["admin@infracloud.io"]
    - key: request.headers[hello]
      values: ["world"]

In this AuthorizationPolicy, we validate the issuer of the key for every request. In this case, it’s supposed to be admin@infracloud.io. If you remember, while creating a JWT token, we provided this as the issuer. We also mention that there has to be a header named hello and its value must be world So only those requests which have a token that is issued by admin@infracloud.io and a valid header will be able to access the frontend service.

Let us apply this policy.

kubectl apply -f authz.yaml

Now let us first access the service without a token and a header and see what response we get.

kubectl exec $(kubectl get pod -l app=productcatalogservice -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl  http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
403

The response is HTTP 403 - Forbidden, as expected. If we pass a valid token, we get HTTP 200 - Success. This means the policy is working just fine.

kubectl exec $(kubectl get pod -l app=productcatalogservice -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl  http://frontend:80/ -o /dev/null --header "Authorization: Bearer $TOKEN" --header "hello:world" -s -w '%{http_code}\n'
200

Let us also see this using postman.

We get RBAC:access denied error when we pass the header as hello:test instead of hello:world

If the user tries to access any other service even with a valid token and a header, it will be denied as the authorization policy that we’ve created allows access only to the frontend service and nothing else.

Hence, using mTLS, JWT Authentication, and Authorization policies, Istio provides finer controls over who accesses your services and what they can do. This fine-grained control is missing in the native options provided in Kubernetes and hence a service mesh like Istio is preferred. You can configure these policies based on your requirements to secure your application.

Summary

Safeguarding the safety and integrity of our applications, authentication, and authorization are of utmost importance. While Kubernetes does offer some solutions out-of-the-box, they fail to provide finer access control options. That’s where service meshes shine and a tool like Istio takes center stage.

Istio simplifies the implementation of authentication and authorization and provides a seamless solution for controlling access. With Istio, we get fine-grained control over who accesses what which helps us fortify our applications.

While the blog post showed how easy it is to leverage Istio, in real-world applications, things are much more complicated. There might be hundreds of services, spread across different clusters accessed by thousands of users.

If you found this blog post helpful, please share it with your peers. If you feel this can be improved, connect with me on LinkedIn to take it forward.

PS: If you're interested to read about my food & travel chronicles, check out my blog on socialmaharaj.com

CNCF Landscape made easy with CNCF Navigator

Atulpriya Sharma — Mon, 05 Jun 2023 08:19:28 +0000

Today, CNCF is among the fastest-growing open source communities globally, with over 500 members, promoting cloud native tech adoption. It manages popular projects like Kubernetes, Prometheus, and Envoy, which are some of the crucial components for building resilient and scalable cloud native applications.

In this blog post, we’ll talk about the CNCF landscape, its features & challenges, and how a tool like the CNCF Navigator makes it easy to navigate the CNCF landscape.

Understanding the CNCF Landscape

If you’ve ever searched for cloud native tools, you would have surely come across the CNCF Landscape. There are so many tools out there that it is overwhelming to understand all of them and choose the right one for your use case.

The aim of the CNCF landscape navigator is to bring all open source and proprietary cloud native projects under one umbrella to give a comprehensive overview of the system. This makes it a single point of interaction for finding any cloud native tool. It also helps developers/teams find the right tool for their requirements.

To bring some system to the chaos, the CNCF landscape created 6 broad categories under which projects are listed. These categories are:

Provisioning: Tools that are used to create the foundation on which cloud native apps are built.
Runtime: Tools that help a container run in a cloud native environment.
Orchestration & Management: Tools that help to handle running & connecting to your cloud native applications.
App Definition & Deployment: Tools that help developers build cloud native applications.
Observability & Analysis: Tools in this category observe all the layers through logging, monitoring & tracing.
Platform: These offerings bundle tools from all the above categories & provide them as a single offering so that you don’t need to choose a tool from each category.

There are further subcategories to each of the categories listed above. Refer to the CNCF landscape Guide to get a detailed overview.

CNCF Landscape

Above is a screenshot of the CNCF landscape. Projects with a White background are open source projects and the ones with a Grey background are proprietary projects. Further, the ones with a dark blue label are CNCF graduated projects, ones with light blue are incubating projects. Read more about CNCF project maturity levels.
Benefits of CNCF Landscape:

Visual Representation: CNCF landscape is a pictorial representation of all the CNCF projects. This graphical representation lists projects based on broad categories thus making it easy to visualize and find different projects. The web version of the landscape is interactive and projects are listed as cards.
Quick & Easy Access to Information: Clicking any project card quickly gives you all the relevant information about the project. Details like the website, GitHub repo, commits & contributions, updates & releases are made available. There are filters available that make it easy to find a project.
Promotes Standardization: All the projects that are listed in the CNCF landscape have the same set of information available. Project details like repo URL, release history, contributions, etc. are common for all the projects. Further to be listed as a CNCF project, certain requirements need to be fulfilled. This helps bring standardization across projects.
Up-to-date: The landscape is updated regularly to reflect the latest changes & developments in the cloud native ecosystem. This ensures that users always have the latest information.
Community Driven: The landscape is developed & maintained by the CNCF community. Anyone can propose to include their cloud native product to be included in this list by raising a PR.

The CNCF landscape offers a comprehensive view of various cloud native technologies & makes it easier for users to explore & discover new technologies. However, as the cloud native landscape is rapidly evolving, the CNCF landscape itself comes with its own set of challenges.
Challenges of CNCF Landscape

The CNCF landscape is constantly evolving. As we write there are 1100+ projects in the landscape collectively having over 3.6Mn GitHub stars with a total funding of close to $6.7Bn. That’s how vast the landscape is and with newer projects added almost every month, it’s only becoming complex. Below are a few challenges that users face while working with the CNCF landscape:

Information Overload: One of the major challenges with the CNCF landscape is its sheer size. With so many projects already added and newer ones being added continuously, it becomes difficult for the users to find the right information they need. Not only that, it makes it difficult for them to find the right tool for their requirement.
Complexity: The CNCF landscape in its current form is complex and hence overwhelming. With the wide variety of tools present, users may find it difficult to clearly understand the specific use case and benefits of a project. Further, identifying the right project, and implementing and managing it in itself is a complex task.
Lack of Guidance: The landscape lists out all the cloud native-related projects. However, it doesn’t provide users with any guidance in terms of which project would be best for their use case, what stack to use, and so on. Without proper guidance, organizations can find it difficult to choose the right project for their need.

From seasoned organizations to newer ones, all of them find it difficult to navigate through the CNCF landscape due to the challenges listed above. The information overload and the sheer complexity along with the lack of guidance make it difficult for organizations to choose the right cloud native tool for their use case.

Thus arises a need for a tool that can declutter this information, reduce the complexity and provide tailor-made suggestions to choose the best tool to suit your requirements. Comes in the CNCF Navigator, a tool that helps you easily navigate through the CNCF landscape & identify the best one for your requirement.

Comes in the CNCF Navigator!

CNCF Navigator

As the name suggests, the tools help you find your way through the vast CNCF landscape and find the right tool for your tech stack. The team spent months together brainstorming and understanding the pain areas associated with identifying the right project.

The CNCF Landscape Navigator provides the following benefits:

Reduces Complexity: Instead of navigating through the vast CNCF landscape, the CNCF Landscape Navigator comes with an interactive Q&A-based smart recommendation engine that helps identify the best CNCF projects that are right for your use case.
Accelerate Time-to-Market: The tool helps you find the optimal CNCF projects, for your tailored use case. So, your team can focus on building & shipping solutions that your customers care about without worrying about which project to choose.

Try out the CNCF Navigator Today!

In its current form, the CNCF Landscape Navigator can suggest tools for Monitoring & Logging space, Service Mesh, Progressive Delivery, Serverless, Cost Management, and Security.

Using the CNCF Landscape Navigator is easy. Head to the CNCF Landscape Navigator, and choose any one category from Monitoring, Logging, Service Mesh, Progressive Delivery, Serverless, Cost Management, and Security. Answer a few simple questions and let the CNCF Navigator suggest the best tool for you.

Machine Learning 101: Everything You Need to Know About It

Atulpriya Sharma — Wed, 05 Apr 2023 08:42:23 +0000

This blog post is adapted from the blog post "Introduction to MLOps" on InfraCloud's blog written by me.

As commonly understood, machine learning is a subset of artificial intelligence that enables computers to learn and make predictions without requiring explicit programming.

Machine learning finds widespread usage across diverse industries. Its applications range from providing personalized movie recommendations such as on YouTube or Netflix to recognizing your voice commands and activating a fan like Alexa.

Even sectors like banking rely on it to identify instances of credit card fraud and introduce chatbots to enhance customer service speed. These examples are just a few instances of how machine learning is employed in everyday life.

Types of Machine Learning

Similar to how humans learn in various ways, there exist techniques by which algorithms can also learn. The following are the three primary categories of machine learning:

Supervised: Supervised learning involves labeled input data, where certain data points are already tagged with the correct answer. For instance, when working with input data comprising images of fruits, each image would be labeled with the corresponding fruit. From this, the model learns and can produce accurate output for new data based on the labeled data. Regression and classification are two types of supervised learning models.
Unsupervised: Unsupervised learning refers to input data that is neither labeled nor classified. The algorithm must analyze this data without any prior information. The model must group unsorted input based on patterns and similarities. As an example, you could provide input consisting of unlabeled images of fruits that the algorithm has never seen before. The algorithm will categorize the fruits into groups based on the patterns it identifies. Clustering and Association are two types of unsupervised learning models.
Reinforcement: Reinforcement learning works based on feedback. The algorithm learns to perform actions in an environment and receives feedback based on those actions. It operates using the trial-and-error method, and over time, the model learns to behave in the environment.

Machine learning models

Machine learning models are at the core of machine learning. These algorithms are trained on datasets and fine-tuned to provide accurate predictions for new data. The outcome of this process is a machine learning model.

There exist various types of machine learning models based on the approach they use to predict, including:

Regression models: Machine learning models that forecast numerical values are designed to identify relationships between dependent and independent variables to make predictions. A regression model is an instance of this type of model. For example, anticipating the stock price using historical data is a regression model. Linear regression stands out as one of the most commonly employed regression models.

Classification models: Machine learning models that forecast categorical values are designed to recognize patterns in data and classify them into specific categories. A classification model is an instance of this type of model. For example, classifying emails as spam or non-spam is accomplished using a classification model. Decision trees and random forests are two popular types of classification models.

Clustering models: Clustering models group data points together by identifying patterns and grouping similar data points into clusters. These models function by grouping data points together based on their similarities. K-Means is an example of a well-known clustering model. For instance, clustering models are used to group customers based on their purchase history.

Neural Network Models: Neural network models are utilized for intricate tasks, including speech and vision, inspired by the human brain. These models operate by leveraging layers of artificial neurons to detect complex patterns in data. Convolutional Neural Network is one of the most widely employed neural network models and is extensively used for image recognition.

Machine Learning Development: Existing Challenges

Despite the progress made in the Artificial Intelligence (AI) and machine learning field, the advancement of associated processes has been slow-paced. Many organizations currently utilize machine learning models for various use cases; however, most of these processes are manual and present several challenges.

Data quality and management: The performance of a machine learning model can be negatively impacted by incomplete or incorrect data. Working manually with various data sources and formats is prone to errors and can impede the process.
Model complexity: Over time, machine learning models can become intricate due to evolving data and environments. The deployment, scaling, and management of complex models can be challenging.
Reproducibility: Recreating machine learning models manually and monitoring changes over time can be challenging due to differences in data, environments, infrastructure, and other factors.
Deployment Complexity: The deployment of machine learning models across diverse environments and systems can be challenging and may necessitate considerable modifications to your infrastructure.
Collaboration: When it comes to machine learning development teams, individuals with diverse expertise, such as data scientists, developers, and operations staff, are typically involved. Without a cohesive process in place, these three groups may work independently, leading to communication gaps and misunderstandings.

MLOps was introduced to automate and streamline various processes that hamper the development and deployment of machine learning models.

By overcoming challenges like incomplete or incorrect data, working with multiple data sources and formats, deploying and scaling complex models, reproducing models in different environments and systems, and siloed teams, MLOps has become a game-changer for the industry.

You can read the complete blog post on Introduction to MLOps.

Follow me on Twitter @TheTechmaharaj for more tech updates. If you're interested to know more about what I do off work, check out my blog socialmaharaj.com :)

Hyderabad's First AWS Community Day - reCap

Atulpriya Sharma — Mon, 20 Mar 2023 07:28:19 +0000

Over the last decade, I've been an IT professional on weekdays and a Travel & Food Blogger on weekends. Most of my weekends were spent on roads or restaurants.

However, the last weekend was different. I attended the first ever AWS Community Days meetup in Hyderabad, India. And this happened just a week after I was inducted into the AWS Community Builder program.

I thought how would I be able to spend almost 8 hours at a tech meetup, well, didn't realize how time passed. So this post is just a recap of Hyderabad's First AWS Community Day Meetup from my eyes :)

The event took place at Radisson Blu hotel in Banjara Hills, which is quite a popular hotel in the city. The event from what I know was attended by close to 200 folks. I was there in time, but the registrations were in full swing. I got my badge and swags. Met some familiar faces, some new and also the organizers.

Before starting the proceedings, one good thing that the organizers did was to have all the speakers come on the stage and introduce themselves first. That way all of us knew who's who.

Post registrations, we started our day with a keynote by Chandra Balani who spoke about the changing landscape of technology in India citing the example of UPI. He also spoke about how AWS has expanded over the years and now have Hyderabad a region.

Faizal who is the chapter lead for AWS Hyderabad talked about the growth of the community and how more Hyderabadis are required to take up the stage. I'm surely looking to contribute to the group!

This was followed by a Women in Tech panel with Ridhima Kapoor, Bhuvaneshwari Subramani and our very own Megha Arora. The ladies spoke about how it's important to celebrate small victories and keep learning constantly. The also spoke about their challenges and emphasized on the importance of support groups, quite an insightful talk.

Post that, there were different tracks that were taking place simultaneously, however I stuck to the talks that I found relevant and interesting.

The first talk by Ayush Jain was Highway to code-driven infrastructure where he spoke about Infrastructure as Code and how tools like AWS CloudFormation can help automate infrastructure deployment making it faster and less prone to errors.

The next talk was by Jones who gave us a sneak peek into Amazon EventBridge and how we can integrate it with other SaaS products along with some helpful tips and tricks. He's an AWS Hero in the serverless space and I just joined the AWS Community Builder group in the serverless space.

Post lunch, we kicked off the proceedings by a talk on Disaster recovery by Neetu Malan who emphasized on the importance of having DR strategies and discussed important topics like RPO,RTO

This was followed by a session on Terraform and Jenkins automation to streamline AWS cloud resources. An insightful talk by Ashok that had many of us interested.

The last one for the day was on GraphQL and AppSync. Abhishek and Vishal help us understand the concepts and gave a deep dive in AppSync and it's features.

There were regular breaks for tea, lunches and even networking. While technical glitches happened on-and-off, the organizers ensured that things happened as they were supposed to. There was also a session about AWS certification where they gave us insights into the various tracks and certification levels offered along with the learning paths.

Overall, it was an amazing event full of learning and meeting new and old people. Thanks to all the organizers for a wonderful event, already looking forward to the monthly meetups and the next community day event!

PS:_ If you're on Twitter, you can also check out this Twitter thread for event updates and pictures :)_

Solving Challenges of Kubernetes YAML Manifest using Monokle

Atulpriya Sharma — Tue, 07 Feb 2023 06:08:56 +0000

Kubernetes has become a popular platform for deploying and managing applications in the cloud-native environment. While it provides many benefits, it also introduces new challenges for developers, particularly when it comes to validating YAML manifests.

The manifests are used to define the desired state of the application and its resources, but incorrect manifests can lead to deployment failures or security vulnerabilities.

In this post, I'll delve into the difficulties of Kubernetes YAML manifest validation and how they can impact the overall deployment process. I'll also give you a quick tour of Monokle and how it can help solve the challenges of Kubernetes YAML manifest validation.

Challenges with Kubernetes YAML Manifests

Complex and Dynamic Configuration: Kubernetes YAML manifests can become complex and difficult to manage as the application and its resources grow. This can lead to difficulties in understanding and validating the configuration, as well as in making changes to it.
Inconsistent and Ambiguous Syntax: Kubernetes YAML manifests use a specific syntax, but there can be inconsistencies and ambiguities in how the syntax is used, leading to difficulties in validation and interpretation.
Managing Versioning and Upgrades: Kubernetes YAML manifests must be kept up to date with the latest version of Kubernetes and its dependencies. This can be a complex and time-consuming task, and incorrect updates can lead to deployment problems or security vulnerabilities.
Managing dependencies between resources: Kubernetes YAML manifests define interdependent resources, making it difficult to ensure that all dependencies are met and that the correct order of operations is followed during deployment.
Lack of Testing and Validation Tools: Kubernetes YAML manifests can be challenging to test and validate, especially against live infrastructure. This makes it difficult to ensure that manifests are correct and secure, and can lead to deployment problems.

Any developer working with Kubernetes YAML manifests can surely related to these challenges.

How Monokle helps overcome the challenges of Kubernetes YAML manifests

Monokle is an open-source IDE for Kubernetes. You can import existing infrastructure code or start fresh with your configuration. Monokle comes as a standalone desktop app, CLI as well as a cloud offering.

I'll talk about one feature of Monokle that helps us solve challenges of Kubernetes YAML Manifests.

Resource Templates in Monokle help ease the creation of resources as well as provide validation against a set of policies.

Create a resource using Monokle Resource Templates

To deploy a simple NGINX application using a resource template, start by launching Monokle and creating a new project.

Choose a basic service deployment template, provide a name and location to save the project, and fill in the deployment settings such as the name of the service, the namespace to deploy to, the image name, the service and target ports, and the service type.

Validate Resources

In Monokle, once manifests have been loaded, the manifest list is displayed separated by resource type in the Navigator.

If there are any validation errors, they will be highlighted in the Editor.

To fix a validation error, such as a policy violation for using the latest image tag, click on "View Images" in the Toolbar, select the image name, choose a specific tag, replace the image tag with a stable version, and check if the error still persists.

Using the Open Policy Agent feature in Monokle helps ensure best practices and security by identifying and mitigating policy errors before deployment to the cluster.

Monokle also allows you to deploy application using Helm and Kustomize whilst helping you validate Kubernetes resources.

Read Get Started - Validate Kubernetes Resources blog post to learn more on how you can use Monokle to solve challenges of Kubernetes YAML Manifest using Monokle

Setting Up Paralus on DigitalOcean

Atulpriya Sharma — Tue, 27 Sep 2022 03:21:53 +0000

One of the cloud platforms that I absolutely enjoy working with is DigitalOcean - the sheer ease of use & the helpful #community makes it a preferred choice for me. Along with the various options it gives to developers like to me try things quickly makes it a platform that I'd recommend.

In this blog post, I'll take you through the steps to setup Paralus on Digital Ocean (DO) using a custom domain and import a local cluster into it.

Paralus is a free, open source tool that enables controlled, audited access to Kubernetes infrastructure. It comes with just-in-time service account creation and user-level credential management that integrates with your RBAC and SSO. Ships as a GUI, API, and CLI.

Let's get started!

Table Of Content:

Pre Requisites
Creating Digital Ocean Cluster
Connecting to Digital Ocean Cluster
- 1. Create API Token
- 2. Configure doctl
Installing Paralus
Configuring DNS Settings
- Accessing The Dashboard
- Importing Existing Cluster

Note: Before you start the installation process, do check out the pre-requisites for installing Paralus.

Pre Requisites

To setup Paralus on Digital Ocean there are a few things that need to done:

A Digital Ocean account - you can register for a Free Digital Ocean account if you don't have one
A Domain Name - with permission to manage DNS settings.
Helm

We'll start with setting up a cluster on Digital Ocean, followed by deploying Paralus to it using helm charts. Once the installation is done, we'll configure the DNS settings for the domain for Paralus to work. After that we'll login to the Paralus dashboard and import a Kubernetes cluster that is running on a local laptop.

Creating Digital Ocean Cluster

Creating a Kubernetes cluster on DO is quite simple. DO offers just one type of Kubernetes cluster and not a variety of offerings like GKE, AWS or AKS. They provide two types of plans when it comes to Nodes - Basic and Professional plans, each of them offering a different configuration.

You need to choose the professional node plan with 3 nodes at the minimum for Paralus to run smoothly.

Login to your DO account and choose Kubernetes -> Create Kubernetes Cluster and provide details like cluster name, region, Kubernetes version, capacity etc.

To know more about how to choose a plan or resize a Kubernetes cluster, check out this document.

Connecting to Digital Ocean Cluster

To connect to your newly created Kubernetes cluster there are two things that you need to do:

Create API Token
Configure doctl

1. Create API Token

You need to generate an API key to be able to access your Kubernetes cluster. You can follow this guide to create a personal access token.

2. Configure doctl

The next step is to configure doctl - a CLI tool provided by DO to interact with their API via command line.

We used a snap package to install the doctl package on our Ubuntu laptop.

Refer to doctl installation document to install it on different environment.

sudo snap install doctl

Create new context by providing the API token generated in the earlier step and switch to this newly created context

doctl auth init --context <NAME> followed by doctl auth switch --context <NAME>

Allow doctl to access the kube-config that will allow you to communicate with the Kubernetes cluster.

sudo snap connect doctl:kube-config

The next step is to configure a certificate to your kubectl configuration. You will get this certificate details after your cluster has been provisioned.

doctl kubernetes cluster kubeconfig save f4739f01-1433-48e1-b991-742a53769fe7

Notice: Adding cluster credentials to kubeconfig file found in "/home/atulpriya/.kube/config"
Notice: Setting current-context to do-ams3-paralus-demo

Once done, you can validate the connectivity using the following command

kubectl get nodes

NAME                   STATUS   ROLES    AGE   VERSION
pool-lhosbqych-7fomd   Ready    <none>   16m   v1.23.9
pool-lhosbqych-7fomi   Ready    <none>   16m   v1.23.9
pool-lhosbqych-7fomv   Ready    <none>   16m   v1.23.9

At this point, you have successfully created a Kubernetes cluster & configured access to it using doctl. The next steps include installing Paralus and importing a local cluster on to it.

Installing Paralus

In the same terminal, you can follow the below steps to deploy Paralus to your DO cluster.

Add helm repo

helm repo add paralus https://paralus.github.io/helm-charts

Install Paralus

   helm install myrelease paralus/ztka \
    -f https://raw.githubusercontent.com/paralus/helm-charts/main/examples/values.dev-generic.yaml \
    --set fqdn.domain="chartexample.com" \
    -n paralus \
    --create-namespace

Note: If you're installing this in a production environment, please use values.yaml and configure the values mentioned here as required.

  NAME: myrelease
  LAST DEPLOYED: Mon Aug 29 17:29:54 2022
  NAMESPACE: paralus
  STATUS: deployed
  REVISION: 1
  NOTES:
    Access the application URL by running these commands:
    Get the EXTERNAL-IP value using following command:
    kubectl get service myrelease-contour-envoy -n paralus

    Add DNS records of following domains such that it resolves to above address:
    - console.chartexample.com
    - *.core-connector.chartexample.com
    - *.user.chartexample.com

    Open http://console.chartexample.com in browser.

    Note: If you are using a cluster with no load-balancer, then the address will be "<pending>".
          If it is Kind or Minikube cluster, check out respective docs to get the external address.

  You can view the recovery link for admin user by running the following command once all the pods are running:

  kubectl logs -f --namespace paralus $(kubectl get pods --namespace paralus -l app.kubernetes.io/name='paralus' -o jsonpath='{ .items[0].metadata.name }') initialize | grep 'Org Admin signup URL:'

Note: It can take upto a few minutes before all the pods are running and you can access the dashboard. You can check the status using watch kubectl get pods -n paralus

Configuring DNS Settings

Once the installation is complete, you need to first get the external IP address provided by the loadbalancer. You can do so by executing the following command:

kubectl get svc myrelease-contour-envoy -n paralus

NAME                      TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                      AGE
myrelease-contour-envoy   LoadBalancer   10.245.58.69   138.68.122.180   80:32722/TCP,443:32656/TCP   2m32s

It may take some time for the loadbalancer to assign the IP address.

Note down the EXTERNAL-IP address for the <releasename>-contour-envoy service.

Navigate to your domain's DNS setting page. The steps for changing DNS settings will vary based on your domain name provider.

While you are on your DNS Setting page, for the selected domain name, you need to add three A records. These will be based on the subdomains provided in the notes section post installation.

Type	Address	Resolves To	TTL
A	console.chartexample.com	138.68.122.180	1 Hour
A	*.core-connector.chartexample.com	138.68.122.180	1 Hour
A	*.user.chartexample.com	138.68.122.180	1 Hour

Accessing The Dashboard

Paralus is installed with a default organization and an admin user. Hence, after installation, you need to set a password for the user. To do so, execute the command that you get after installing Paralus.

kubectl logs -f --namespace paralus $(kubectl get pods --namespace paralus -l app.kubernetes.io/name='paralus' -o jsonpath='{ .items[0].metadata.name }') initialize | grep 'Org Admin signup URL:'

Org Admin signup URL:  http://console.chartexample.com/self-service/recovery?flow=de34efa4-934e-4916-8d3f-a1c6ce65ba39&token=IYJFI5vbORhGnz81gCjK7kucDVoiuQ7j

Note: The password recovery link generated while deploying Paralus is valid only for 10 minutes. For any reason if the link is expired, refer to our troubleshooting guide to re-generate the password reset link.

Access the URL in a browser, and provide a new password. In a new browser window/tab navigate to http://console.chartexample.com and log in with the following credentials:

username: admin@paralus.local - or the one you specified in values.yaml
password: <The one you entered above>

You'll be taken to the projects page where you'll see a default project.

Importing Existing Cluster

Everything in Paralus is grouped into Projects. Each project will have clusters, users and groups associated with it. Hence the first step it to create a new project.

Click on New Project to create a new project and then import a cluster in that project. The cluster we are importing is a minikube cluster hosted on my laptop.

Click Continue and download the bootstrap yaml file by clicking Import Bootstrap YAML. This will download the YAML file that is required to connect your cluster with Paralus.

Apply the bootstrap configuration yaml file

kubectl apply -f mylocalcluster.yaml

Wait for the changes to take place. On the dashboard you will see that the cluster is imported successfully. It usually takes 3-5 minutes for the status to update.

Select your newly imported cluster and click on kubectl to access the prompt and interact with your cluster from the dashboard.

A kubectl console will open in the bottom half of the screen, enter your kubectl commands to interact with your cluster.

Congratulations! You've successfully deployed Paralus on Digital Ocean Kubernetes cluster and imported a local cluster.

If you have any issues with Paralus, feel free to reach out to me :)

Setup Paralus on Kind Cluster

Atulpriya Sharma — Fri, 15 Jul 2022 09:28:23 +0000

Paralus is the newest Opensource project that helps you with zero trust access management for Kubernetes.

It gives you a single dashboard that allows you to manage all your clusters from one portal. In this article, I'll show we can Install Paralus on a local Kind cluster.

You can refer to the Paralus website to learn more about Paralus.

Kind

The following section talks about installing Paralus in a Kind cluster. Kind is a tool used to run local Kubernetes clusters using Docker container nodes. Learn more about Kind.

Installing and Configuring Kind

If you don't already have Kind installed on your local system, you can do so by following the Kind Quickstart Documentation. The default settings are good enough to get you started.

The next step is to create a Kind cluster. To do that you can create a copy of this configuration file and use that to create a cluster.

kind create cluster --config cluster.yaml

Note down the IP address of the control plane by running the following command

docker container inspect kind-control-plane --format '{{ .NetworkSettings.Networks.kind.IPAddress }}'

172.20.0.2

Installing Paralus

Add the paralus helm repository

helm repo add paralus https://paralus.github.io/helm-charts
helm repo update

   helm install myrelease paralus/ztka \
    -f https://raw.githubusercontent.com/paralus/helm-charts/main/examples/values.dev-generic.yaml \
    --set fqdn.domain="paralus.local" \
    -n paralus \
    --create-namespace

Note: In case you get an error, run helm dependency build to build the dependencies.

You'll see the following output if the installation succeeds:

NAME: ztkarelease
LAST DEPLOYED: Wed Jun 15 09:05:49 2022
NAMESPACE: paralus
STATUS: deployed
REVISION: 1
NOTES:
1. Access the application URL by running these commands:
  Open http://console.paralus.local in browser.

You can view the recovery link for admin user by running the following command once all the pods are running:

kubectl logs -f --namespace paralus $(kubectl get pods --namespace paralus -l app.kubernetes.io/name='paralus' -o jsonpath='{ .items[0].metadata.name }') initialize | grep 'Org Admin signup URL:'

Note: It can take upto a few minutes before all the pods are running and you can access the dashboard. You can check the status using watch kubectl get pods

Configuring /etc/hosts

Since we are deploying Paralus on local cluster, we need to update the /etc/hosts file with the IP Address/Ingress Host name to access the dashboard.
In order to do that, edit the /etc/hosts file using your favourite editor and add the following line at the end of it along with the IP address obtained and save it.

172.20.0.2 console.paralus.local

Refer to the value of fqdn.domain in your values.yaml file to find the default host.

Open your favorite web browser and navigate to http://console.paralus.local, you will be see the dashboard with the login screen

Resetting Default Password

Paralus comes configured with default credentials that allow you to access the dashboard.

In order to get the Password Reset URL, copy the command displayed after helm install and execute it

kubectl logs -f --namespace paralus $(kubectl get pods --namespace paralus -l app.kubernetes.io/name='paralus' -o jsonpath='{ .items[0].metadata.name }') initialize | grep 'Org Admin signup URL:'

Org Admin signup URL:  http://console.paralus.local/self-service/recovery?flow=9ec13c6f-414e-4cb5-bf4c-def35973118f&token=ge6bi6zmyzUlQrHlYTOCDeItV82hT08Y

Note: The password recovery link generated while deploying Paralus is valid only for 10 minutes. For any reason if the link is expired, refer to the troubleshooting guide to re-generate the password reset link.

Access the URL in a browser, and provide a new password.

Accessing Paralus Dashboard

In a new browser window/tab navigate to http://console.paralus.local and log in with the following credentials:

username: admin@paralus.local - or the one you specified in values.yaml
password: <The one you entered in the earlier section>

You'll be taken to the projects page where you'll see a default project.

Importing Existing Cluster

Everything in Paralus is grouped into Projects. Each project will have clusters, users and groups associated with it. Hence the first step it to create a new project.

Click on New Project to create a new project and then import a cluster in that project.

Click Continue and download the bootstrap yaml file by clicking Import Bootstrap YAML. This will download the YAML file that is required to connect your cluster with Paralus.

Configuring Network

Getting Cluster ID and Hostname

Open the downloaded yaml file in a text editor and look for clusterID

data:
  clusterID: 5dceca49-c6cd-4a2b-b65a-f193c4fa001f
  relays: '[{"token":"cakmpdvjd030q1q53p9g","addr":"console.paralus.local:80","endpoint":"*.core-connector.paralus.local:443","name":"paralus-core-relay-agent","templateToken":"cakl93fjd030q1q53p5g"}]'

With the clusterID identified, we need to update the hosts file. This becuase we are using hostname to route traffic.

5dceca49-c6cd-4a2b-b65a-f193c4fa001f.user.paralus.local
5dceca49-c6cd-4a2b-b65a-f193c4fa001f.core-connector.paralus.local

Updating /etc/hosts

Add two new lines in /etc/hosts file along with the IP address obtained

172.20.0.2 5dceca49-c6cd-4a2b-b65a-f193c4fa001f.user.paralus.local
172.20.0.2 5dceca49-c6cd-4a2b-b65a-f193c4fa001f.core-connector.paralus.local

Your final /etc/hosts file should be something like the following

172.20.0.2 console.paralus.local
172.20.0.2 5dceca49-c6cd-4a2b-b65a-f193c4fa001f.user.paralus.local
172.20.0.2 5dceca49-c6cd-4a2b-b65a-f193c4fa001f.core-connector.paralus.local

Accessing Existing Cluster

With all the changes in place, it's time to apply the bootstrap yaml file that we download while importing an existing cluster

kubectl apply -f mylocalcluster.yaml

Wait for the changes to take place. On the dashboard you will see that the cluster is imported successfully. It usually takes 3-5 minutes for the status to update.

You can also execute kubectl get pods to check the status.

Select your newly imported cluster and click on kubectl to access the prompt and interact with your cluster from the dashboard.

A kubectl console will open in the bottom half of the screen, enter your kubectl commands to interact with your cluster.

And that's how you can setup Paralus on a local Kind cluster for trying it out before taking it to production environment.

Follow me at @TheTechmaharaj for more :)

Guestbook application using Fission & CockroachDB

Atulpriya Sharma — Fri, 01 Apr 2022 09:07:18 +0000

Fission provides you with a serverless framework that you can deploy on your Kubernetes clusters.There are various use cases where you can use Fission, and today we'll show you how to develop a guestbook application with Fission in Go using CockroachDB as a database.

Serverless Guestbook Application

The guestbook is composed with four REST APIs and each API consist of a function and an HTTP trigger. This application allows a user to create, edit and delete a message. You can submit a message, retrieve a list of messages, delete a message all by means of REST APIs.
You can clone Fission REST API Repo and follow the guide to install/try guestbook sample.

Create Fission Objects for REST API

A REST API uses HTTP method to determine what's the action server needs to perform on resource(s) represents in the URL.

POST   http://api.example.com/user-management/users/{id}
PUT    http://api.example.com/user-management/users/{id}
GET    http://api.example.com/user-management/users/{id}
DELETE http://api.example.com/user-management/users/{id}

To create a REST API with fission, we need to create following things to make it work:

HTTP Trigger with specific HTTP method and URL contains the resource type we want to manipulate with. Read more about HTTP Triggers
Function to handle the HTTP request. Read more about Function

Installation

HTTP Trigger

The first step is to create an HTTP trigger for your function

$ fission httptrigger create --url /guestbook/messages --method POST --function restapi-post --name restpost

There are 3 important elements in the command:

method: The HTTP method of REST API
url: The API URL contains the resource placeholder
function: The function reference to a fission function

As a real world REST API, the URL would be more complex and contains the resource placeholder.
To support such use cases, you can change URL to something like following:

$ fission httptrigger create --url "/guestbook/messages/{id:[0-9]+}" --method GET --function restapi-get --name restgetpart

Since fission uses gorilla/mux as underlying URL router, you can write regular expression in URL to filter out illegal API requests.

route-restGetPart.yaml

$ fission httptrigger create --url "/guestbook/messages/{id:[0-9]+}" --method GET --function restapi-get --name restgetpart

Function

To handle a REST API request, normally a function need to extract resource from the request URL. In Fission, you can get the resource value from request header directly as we described in Request Payload.

That means you can get value from header with key X-Fission-Params-Id if URL is /guestbook/messages/{id}.

In Go, you can use CanonicalMIMEHeaderKey to transform letter case.

rest-api/api.go

import (
    "net/textproto"
)

const (
    URL_PARAMS_PREFIX = "X-Fission-Params"
)

func GetPathValue(r *http.Request, param string) string {
    // transform text case
    // For example: 'id' -> 'Id', 'fooBAR' -> 'Foobar', 'foo-BAR' -> 'Foo-Bar'.
    param = textproto.CanonicalMIMEHeaderKey(param)

    // generate header key for accessing request header value
    key := fmt.Sprintf("%s-%s", URL_PARAMS_PREFIX, param)

    // get header value
    return r.Header.Get(key)
}

When Golang server receive HTTP requests, it dispatches entrypoint function and passes whole response writer and request object to the function.

func MessageGetHandler(w http.ResponseWriter, r *http.Request) {
    ...
}

In this way, you can access query string and message body as usual.

rest-api/api.go

func GetQueryString(r *http.Request, query string) string {
    return r.URL.Query().Get(query)
}

rest-api/api.go

body, err := ioutil.ReadAll(r.Body)
if err != nil {
    err = errors.Wrap(err, "Error reading request body")
    log.Println(err.Error())
    w.WriteHeader(http.StatusBadRequest)
    w.Write([]byte(err.Error()))
    return
}

CockroachDB Setup

In guestbook application we need to store messages in a database.
Since fission is build on top of kubernetes, it's very easy to achieve this by creating Kubernetes Service(svc) and Deployment.
For this sample application, we are using CockroachDB.

We also have a post on using PostgreSQL with Fission that you might want to read too.

Add cockroachdb helm repo

helm repo add cockroachdb https://charts.cockroachdb.com/
helm repo update

Install cockroachdb using helm and provide values from cockroachdb.yaml

helm install my-release --values cockroachdb.yaml cockroachdb/cockroachdb

Guestbook Application Setup

Create the go environment

fission env create --name go --image fission/go-env-1.16 --builder fission/go-builder-1.16

Create a sourcepackage from the rest-api folder.
It is required to create a package.

zip -j restapi-go-pkg.zip rest-api/*

Create a package from the source archive

fission pkg create --name restapi-go-pkg --sourcearchive restapi-go-pkg.zip --env go

Create functions for GET, POST, DELETE, UPDATE

fission fn create --name restapi-delete --executortype newdeploy --maxscale 3 --env go --pkg restapi-go-pkg --entrypoint MessageDeleteHandler
fission fn create --name restapi-update --executortype newdeploy --maxscale 3 --env go --pkg restapi-go-pkg --entrypoint MessageUpdateHandler
fission fn create --name restapi-post --executortype newdeploy --maxscale 3 --env go --pkg restapi-go-pkg --entrypoint MessagePostHandler
fission fn create --name restapi-get --executortype newdeploy --maxscale 3 --env go --pkg restapi-go-pkg --entrypoint MessageGetHandler

Create HTTPTriggers for the endpoints for the above created functions

fission httptrigger create --url /guestbook/messages --method POST --function restapi-post --name restpost
fission httptrigger create --url "/guestbook/messages/{id:[0-9]+}" --method PUT --function restapi-update --name restupdate
fission httptrigger create --url "/guestbook/messages/{id:[0-9]+}" --method GET --function restapi-get --name restgetpart
fission httptrigger create --url "/guestbook/messages/{id:[0-9]+}" --method DELETE --function restapi-delete --name restdelete
fission httptrigger create --url "/guestbook/messages/" --method GET --function restapi-get --name restget

Fission Spec

The entire installation can be done using a single block of fission spec commands as shown below

fission spec init
fission env create --name go --image fission/go-env-1.16 --builder fission/go-builder-1.16 --spec
fission pkg create --name restapi-go-pkg --sourcearchive restapi-go-pkg.zip --env go --spec
fission fn create --name restapi-delete --executortype newdeploy --maxscale 3 --env go --pkg restapi-go-pkg --entrypoint MessageDeleteHandler --spec
fission fn create --name restapi-update --executortype newdeploy --maxscale 3 --env go --pkg restapi-go-pkg --entrypoint MessageUpdateHandler --spec
fission fn create --name restapi-post --executortype newdeploy --maxscale 3 --env go --pkg restapi-go-pkg --entrypoint MessagePostHandler --spec
fission fn create --name restapi-get --executortype newdeploy --maxscale 3 --env go --pkg restapi-go-pkg --entrypoint MessageGetHandler --spec
fission httptrigger create --url /guestbook/messages --method POST --function restapi-post --spec --name restpost
fission httptrigger create --url "/guestbook/messages/{id:[0-9]+}" --method PUT --function restapi-update --spec --name restupdate
fission httptrigger create --url "/guestbook/messages/{id:[0-9]+}" --method GET --function restapi-get --spec --name restgetpart
fission httptrigger create --url "/guestbook/messages/{id:[0-9]+}" --method DELETE --function restapi-delete --spec --name restdelete
fission httptrigger create --url "/guestbook/messages/" --method GET --function restapi-get --spec --name restget

It will create a specs folder with all the required yaml files post which you can apply the changes

fission spec apply

Testing The Guestbook Application

Since this guestbook application is created using REST APIs, we first need to export the $FISSION_ROUTER along with the port

export PORT=8889
kubectl --namespace fission port-forward $(kubectl --namespace fission get pod -l svc=router -o name) $PORT:8888
export FISSION_ROUTER=127.0.0.1:$PORT

Create a post

curl -v -X POST \
    http://${FISSION_ROUTER}/guestbook/messages \
    -H 'Content-Type: application/json' \
    -d '{"message": "hello world!"}'

Get all posts

curl -v -X GET http://${FISSION_ROUTER}/guestbook/messages/

It will return a list of all the messages


[
    {
        "id": 366739357484417025,
        "message": "hello world!",
        "timestamp": 1531990369
    },
    {
        "id": 366739413774237697,
        "message": "hello world!",
        "timestamp": 1531990387
    },
    {
        "id": 366739416644550657,
        "message": "hello world!",
        "timestamp": 1531990399
    }
]

You can also get a single post using the id

curl -v -X GET http://${FISSION_ROUTER}/guestbook/messages/366456868654284801

Updating a post

curl -v -X PUT \
    http://${FISSION_ROUTER}/guestbook/messages/366456868654284801 \
    -H 'Content-Type: application/json' \
    -d '{"message": "hello world again!"}'

Deleting a post

curl -X DELETE \
    http://${FISSION_ROUTER}/guestbook/messages/366456868654284801 \
    -H 'Cache-Control: no-cache'

Conclusion

At this point you know how to create a simple guestbook application using REST APIs and database on Fission.This was a simple application to show you the capabilities of Fission.You can try to create your own application which may be more complex than this one.

This article was originally posted on Fission.io