DEV Community: Arvind Sharma

Istio IP based Whitelisting

Arvind Sharma — Sat, 22 Oct 2022 09:51:02 +0000

Introduction

You might have seen Staff Only signboards in malls, restaurant and other public places. In general, while you are free to use or roam around public places, there are some place which only authorized entities are allowed, like kitchen in an restaurant.

Similarly while most of the services on the internet can be accessed by the public, there are some services which can only be accessed by Authorized users. Usually such services have sensitive information, breach in which might lead to application compromise or other devastating consequences.
It is therefore important to make sure that such services are secured to only authorized entity. One such measure is Whitelisting.

What is Istio

Istio extends Kubernetes to establish a programmable, application-aware network using the powerful Envoy service proxy. Working with both Kubernetes and traditional workloads, Istio brings standard, universal traffic management, telemetry, and security to complex deployments

Whitelisting in Istio

Note: It is assumed that the reader has already setup Istio within the cluster.
Istio provides capability of allowing/denying access based on IP list. It achieves it through AuthorizationPolicy.

Authorization Policy

Istio has provided a wonderful documentation on Authorization Policy. I would highly recommend the reader to go through them for finer nuances. For our scenario, we will work with selector, rules and action.

At server side Envoy proxy, Istio through AuthorizationPolicy enforces allowing/denying access of inbound traffic. When a request comes to proxy, authorization engines, checks the incoming context against enforced policy and returns appropriate access as mentioned in the policy.

Implementing IP based Whitelisting using Authorization Policy

We can enforce multiple authorization checks, but in this example, we will restrict our policy to Whitelist only.

Suppose, you want to enforce Whitelist to path /my_critical_service to only a set of trusted IP (say xxx.xxx.xxx.xxx/y,aaa.aaa.aaa.aaa/b), we can achieve it by applying the below manifest. The below manifest will DENY all request to paths (/my_critical_service) which are not mentioned in the IP blocks list.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: <INSERT APPROPRIATE NAME>
 namespace: <INSERT NAMESPACE>
spec:
 selector:
   matchLabels:
     key_for_istio_metdata: value_for_istio_metadata
 action: DENY
 rules:
 - from:
   - source:
       notIpBlocks: ["xxx.xxx.xxx.xxx/y","aaa.aaa.aaa.aaa/b"]
   to:
   - operation:
       paths: ["/my_critical_service/*"]

Let's bisect to understand the above manifest.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: <INSERT APPROPRIATE NAME>
 namespace: <INSERT NAMESPACE>

Once Istio is setup, we can then use its CR, Authorization Policy. Assign appropriate metadata based on Istio installation.

spec:
 selector:
   matchLabels:
     key_for_istio_metdata: value_for_istio_metadata
 action: DENY
 rules:
 - from:
   - source:
       notIpBlocks: ["xxx.xxx.xxx.xxx/y","aaa.aaa.aaa.aaa/b"]
   to:
   - operation:
       paths: ["/my_critical_service/*"]

As mentioned earlier, Authorization Policy provides many options for enforcing policy checks, but for our task we have used selector, action and rules appropriately for IP based whitelisting.

selector field is optional, which is used for selecting scope of our policy, i.e Target Workload where we want to enforce policy checking. Since we will be using Istio for Ingress, assign appropriate label key and values for identifying it.
action field is used for enforcing appropriate action for set of rules. We can ALLOW or DENY request based on rules. For our task, we will DENY any request which is not matching our rules.
rules field specifies list of criteria for actions to be enforced. We will be using from and to rules for our example.
from rule, specifies the source of the request. We add trusted sources in notIpBlocks, so that we can DENY all request which are not trusted.
to rule, specifies the operation of a request. In our scenario, we want to enforce whitelist for our my_critical_service path and so we provide appropriate path of our service within the rule.

And that's all. Now you can replace or add some of your own criteria to make your network secure!

Conclusion

We have seen in this blog, on how to enforce IP based whitelisting using Authorization Policy in Istio. Hope you found this blog helpful.

P.S: Cover Image Credit: S. Hermann & F. Richter from Pixabay

Monitoring Keycloak using Prometheus Operator - Kubernetes & Helm Charts

Arvind Sharma — Sat, 25 Jun 2022 09:55:30 +0000

Introduction

Just like how a surveillance system over a compound wall enhances the security of our homes, Keycloak too requires continuous surveillance to better safeguard its application.

This tutorial assumes that the reader has basic understanding on Keycloak and it helps the readers to set up Prometheus Operator to monitor their Keycloak.

Setup

Before we begin, let us first, visualize what we will be doing to achieve our target, to monitor Keycloak using Prometheus Operator.

Here, let us assume that Keycloak is already installed on Keycloak Namepace.

We will then:

Install Prometheus Operator on Monitoring Namespace which will automatically deploy Prometheus pod.
Enable Keycloak to publish its metrics at keycloak-metrics Service.
Create a Service Monitor (CRD provided by Operator) which points to the keycloak-metrics Service and attach it to our Prometheus Pod.

For this tutorial, I have used Keycloak helm chart from Bitnami. Feel free to use other helm charts and adjust the parameters accordingly.

Installing Prometheus Operator

We will install the Prometheus Operator using Helm charts from prometheus-community. Feel free to use any other helm chart and change the parameters accordingly.

Adding Helm Repository



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

Install Prometheus-Operator

Note: Adjust other parameters accordingly based on requirements.

custom-values.yaml



      ...
      prometheus:
        prometheusSpec:
          serviceMonitorSelector:
            matchLabels:
              <Service Monitor Label Key>: <Service Monitor Label Value>
      ...

We are intimating Prometheus to look out for a Service Monitor by adding labels into serviceMonitorSelector.
Remember the labels, as we will have to use the same labels while creating Service Monitor later in this tutorial.

Once custom-values.yaml are modified according to the requirement, install Prometheus-Operator using below command



helm install -f custom-values.yaml --namespace=[MONITORING_NAMESPACE] [RELEASE_NAME] prometheus-community/kube-prometheus-stack

Exposing Keycloak Metrics

Ultimately, our aim is to monitor Keycloak's metrics. Keycloak provides options to make it's metrics available for scraping and monitoring. To enable it, make sure to adjust this parameter to Keycloak helm's values.yaml

values.yaml



      ...
      metrics:
        enabled: true
      ...

Note:
By default, keycloak-metrics Service will include http-management port, but the metrics for scraping are enabled at http port (80). So, make sure you patch the keycloak-metrics Service to include http port in its ports specifications.

Service Monitors

Now that we have Prometheus-Operator running and Keycloak making it's metrics available at http port, how do we point the Prometheus to scrape at the http port where Keycloak furnishes it's metrics?

The answer is Service Monitors. Service Monitors are used by Prometheus to automatically detect it's target service to scrape data. Refer here for more information.

Since during our installation, we had notified the Prometheus to look out for a Service Monitor by providing labels in serviceMonitorSelector, we will now create that service monitor with the information of our keycloak-metrics service.

Deploy the below manifest.
Note: This manifest should be deployed only after the Prometheus-Operator is installed. As we are attaching this Service Monitor to Prometheus, therefore it must be there in the namespace where this Service Monitor is deployed.

Service Monitor Manifest



apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: <Insert Appropriate Name for Service Monitor>
  Namespace: <MONITORING_NAMESPACE>
  labels:
    <Service Monitor Label Key>: <Service Monitor Label Value>
spec:
  endpoints:
    - ports: http
      path: /auth/realms/master/metrics
      interval: <Select Appropriate Intervals at which the Metrics will be scraped automatically>
  selector:
    matchLabels:
      app.kubernetes.io/component: metrics
  namespaceSelector:
    matchNames:
      - <Insert Namespace where Keycloak is installed>

Note: Make sure that the metadata.labels have the same key/values as the ones we have provided in serviceMonitorSelector during Prometheus-Operator installation.

I will now breakdown the manifest for better understanding.



  endpoints:
    - ports: http
      path: /auth/realms/master/metrics
      interval: <Select Appropriate Intervals at which the Metrics will be scraped automatically>

In endpoints of Service Monitor specification, we mention at which port to scrape, what path to scrape, and when (interval) to scrape.

Note: /auth/realms/master/metrics will publish the data for all the realms.



  selector:
    matchLabels:
      app.kubernetes.io/component: metrics
  namespaceSelector:
    matchNames:
      - <Insert Namespace where Keycloak is installed>

The above two selectors provide the service monitor with information about the service which will publish the data. So make sure you provide appropriate selector labels for keycloak-metrics service and namespace where Keycloak is installed.

And that's it! Prometheus will now start scraping the Keycloak metrics automatically at given intervals. To visualize them, you now can open the dashboard and view the metrics!

Summary

By going through this tutorial, we will now be able to monitor and analyze Keycloak metrics and view them on customizable Dashboards of Prometheus/Grafana.

Thanks for checking out this post!

Cover Image credits: Image by Lorenzo Cafaro from Pixabay