{"id":7416,"date":"2023-09-27T08:00:28","date_gmt":"2023-09-27T02:30:28","guid":{"rendered":"https:\/\/www.upnxtblog.com\/?p=7416"},"modified":"2023-09-23T13:13:46","modified_gmt":"2023-09-23T07:43:46","slug":"enforcing-policies-with-kubewarden-on-amazon-eks","status":"publish","type":"post","link":"https:\/\/www.upnxtblog.com\/index.php\/2023\/09\/27\/enforcing-policies-with-kubewarden-on-amazon-eks\/","title":{"rendered":"Enforcing policies with Kubewarden on Amazon EKS"},"content":{"rendered":"
<\/div>

According to Red Hat’s 2022 State of Kubernetes Security Report<\/a>, respondents stated that exposures due to misconfigurations in their container and Kubernetes environments (46%) is nearly three times the level of concern over attacks (16%), with vulnerabilities as the second-leading cause of worry (28%). Important settings, such as role-based access control (RBAC) and security contexts, are critical to the security posture of a cluster. One of the most important mis configuration is pod that lacks correct security configurations. Kubernetes offered Pod Security Policy (PSP)<\/a> mechanism to regulate pod security. PSPs define a set of security parameters that pods must fulfil before being created or updated in a cluster. However, PSPs have been deprecated as of Kubernetes version 1.21 due to serious usability problems, and have been removed in Kubernetes version 1.25.<\/p>\n

PSPs are decommissioned in favor of Pod Security Admission (PSA), a built-in admission controller that implements the security measures described in the Pod Security Standards (PSS). There are also several Policy-as-Code (PaC) solutions available for Kubernetes that are more flexible than PSS and also provide guardrails to guide cluster users, prevent unwanted behaviors, through prescribed and automated controls. Following are some of the examples<\/p>\n\n\n\n\n\n\n\n
PaC Solution<\/strong><\/td>\nLink<\/strong><\/td>\nCNCF Project Status<\/strong><\/td>\n<\/tr>\n
Open Policy Agent<\/td>\nhttps:\/\/www.openpolicyagent.org\/<\/td>\nGraduated<\/strong><\/td>\n<\/tr>\n
OPA\/gatekeeper<\/td>\nhttps:\/\/github.com\/open-policy-agent\/gatekeeper<\/td>\nGraduated<\/strong><\/td>\n<\/tr>\n
Kyverno<\/td>\nhttps:\/\/kyverno.io\/<\/td>\nIncubating<\/strong><\/td>\n<\/tr>\n
Kubewarden<\/td>\nhttps:\/\/www.kubewarden.io\/<\/td>\nSandbox<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

PaC solutions uses Kubernetes Dynamic Admission Controllers<\/a> to intercept the Kubernetes API server request flow, via a webhook call, and mutate and validate request payloads, based on policies written and stored as code. Mutation and validation happen before the API server request results in a change to the cluster.<\/p>\n

To implement Pod security<\/a>, Kubernetes users can choose between PSA or PaC, both solutions can coexist with PSP in the same cluster. Considering PaC solutions are more flexible and more granular and it is not just focused on pods but can also be used against different resources and actions. It can further be used to implement behaviors that are not necessarily security related, such as best practices, organizational standards, etc.<\/p>\n

In this post, we are going to look at PaC solution – Kubewarden<\/a>, a policy engine for Kubernetes. It doesn\u2019t require users to learn new Domain Specific Language or a query language instead policies can be authored in your favorite programming language. Kubewarden policies can also be distributed using container registries and could be integrated to your existing infrastructure and processes via CI\/CD pipelines.<\/p>\n\n

Use Case<\/h2>\n

Kubewarden installs as an Kubernetes Dynamic Admission Controller<\/a>, which receives webhook events when an API object changes. It validates incoming requests using policies written in WebAssembly. By using WebAssembly, users can write Kubernetes policies using their favorite programming language, as long as the language can produce Wasm binaries.<\/p>\n

Kubewarden has three main components which you will interact with:<\/p>\n

    \n
  1. PolicyServer<\/strong> – component which executes the Kubewarden policies when requests arrive and validates them.<\/li>\n
  2. ClusterAdmissionPolicy<\/strong> – defines how policies evaluate requests.<\/li>\n
  3. AdmissionPolicy<\/strong> – policy will process only the requests that are targeting the Namespace<\/li>\n<\/ol>\n

    We will show you in this article how Kubernetes cluster administrators can validate and mutate configurations.<\/p>\n

    Prerequisites<\/h2>\n

    We will assume that you already have an EKS cluster up and running. If you don\u2019t have the cluster, please refer this link<\/a> to get started with Amazon EKS. Please note: Your k8s cluster version must be above v1.14.<\/p>\n

    Install Kubewarden on your cluster<\/h2>\n

    Kubewarden installation is easy and the output from the install process is as shown below.<\/p>\n

    Install cert-manager<\/h3>\n

    kubectl apply -f https:\/\/github.com\/jetstack\/cert-manager\/releases\/latest\/download\/cert-manager.yaml<\/a><\/code><\/p>\n

    \"\"
    Image – Install cert-manager<\/figcaption><\/figure>\n

    Check if cert-manager<\/code> is up and running<\/h3>\n

    kubectl wait --for=condition=Available deployment --timeout=2m -n cert-manager \u2013all<\/code><\/p>\n

    \"\"
    Image – Check if cert-manager is up and running<\/figcaption><\/figure>\n

    Deploy Kubewarden stack using helm charts<\/h3>\n

    helm repo add kubewarden https:\/\/charts.kubewarden.io<\/a><\/code><\/p>\n

    \"\"
    Image – Deploy Kubewarden stack<\/figcaption><\/figure>\n

     <\/p>\n

    helm install --wait -n kubewarden --create-namespace kubewarden-crds kubewarden\/kubewarden-crds<\/code><\/p>\n

    \"\"
    Image – Deploy Kubewarden stack<\/figcaption><\/figure>\n

    helm install --wait -n kubewarden kubewarden-controller kubewarden\/kubewarden-controller<\/code><\/p>\n

    \"\"
    Image – Deploy Kubewarden stack<\/figcaption><\/figure>\n

    helm install --wait -n kubewarden kubewarden-defaults kubewarden\/kubewarden-defaults<\/code><\/p>\n

    \"\"
    Image – Deploy Kubewarden stack<\/figcaption><\/figure>\n

    Now that we have deployed Kubewarden, lets enforce our first policy in the next section.<\/p>\n

    Demonstration on validating privileged containers<\/h2>\n

    The use of privileged containers is not a good security practice. By using privileged containers, it gives the container access to all of the capabilities that a host has. Compromised containers with privileged access can affect other containers operating on the host as well. In this demonstration, we will show you how to establish a policy that prevents pods that require privileged capabilities from running.<\/p>\n

    First, let\u2019s create the policy below using kubectl apply<\/code> command as below. This policy below will not allow a process to run in a privileged mode.<\/p>\n

    kubectl apply -f - <<EOF\r\napiVersion: policies.kubewarden.io\/v1alpha2\r\nkind: ClusterAdmissionPolicy\r\nmetadata:\r\n\u00a0 name: psp-allowprivilegeescalation\r\nspec:\r\n\u00a0 module: registry:\/\/ghcr.io\/kubewarden\/policies\/allow-privilege-escalation-psp:v0.1.11\r\n\u00a0 rules:\r\n\u00a0\u00a0\u00a0 - apiGroups:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 - \"\"\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 apiVersions:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 - v1\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 resources:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 - pods\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 operations:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 - CREATE\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 - UPDATE\r\n\u00a0 mutating: false\r\n\u00a0 settings:\r\n\u00a0\u00a0\u00a0 default_allow_privilege_escalation: false\r\nEOF<\/pre>\n
    \"\"
    Image – Create the policy<\/figcaption><\/figure>\n
    Now that policy has been created, let\u2019s create a NGINX pod with privileged access, as shown in the YAML block below.<\/p>\n
    kubectl apply -f - <<EOF\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n\u00a0 name: nginx\r\nspec:\r\n\u00a0 containers:\r\n\u00a0 - name: nginx\r\n\u00a0\u00a0\u00a0 image: nginx\r\n\u00a0\u00a0\u00a0 securityContext:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 allowPrivilegeEscalation: true\r\n\u00a0 - name: sidecar\r\n\u00a0\u00a0\u00a0 image: sidecar\r\nEOF<\/pre>\n
    \"\"
    Image – Create a NGINX pod with privileged access<\/figcaption><\/figure>\n
    As shown above, the pod creation fails as it contains the allowPrivilegeEscalation: true<\/code> in the above code snippet. This is one of the best security practices where privilege escalations on pods should not be allowed.<\/p>\n
    Let’s move to next demo which is on blocking pods running as root<\/p>\n
    Demonstration on blocking pods running as root<\/h2>\n
    Running containers as \u2018root\u2019 is not good security practice. This gives the container access to all of the capabilities that a host has and compromised containers with root access can affect other containers operating on the host. In this demonstration, we will show you how to establish a policy that prevents pods that require “root” capabilities from running.<\/p>\n
    First, let\u2019s create the policy below using kubectl apply<\/code> command as below. This policy below will not allow containers to run in root mode.<\/p>\n
    kubectl apply -f - <<EOF\r\napiVersion: policies.kubewarden.io\/v1alpha2\r\nkind: ClusterAdmissionPolicy\r\nmetadata:\r\n\u00a0 name: psp-usergroup\r\nspec:\r\n\u00a0 module: registry:\/\/ghcr.io\/kubewarden\/policies\/user-group-psp:v0.2.0\r\n\u00a0 rules:\r\n\u00a0\u00a0\u00a0 - apiGroups:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 - \"\"\r\n\u00a0 \u00a0\u00a0\u00a0\u00a0apiVersions:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 - v1\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 resources:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 - pods\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 operations:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 - CREATE\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 - UPDATE\r\n\u00a0 mutating: true\r\n\u00a0 settings:\r\n\u00a0\u00a0\u00a0 run_as_user:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 rule: MustRunAsNonRoot\r\n\u00a0\u00a0\u00a0 supplemental_groups:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 rule: MustRunAs\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 ranges:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0- min: 1000\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 max: 65535\r\nEOF<\/pre>\n
    \"\"
    Image – Create the policy<\/figcaption><\/figure>\n
    Now that policy has been created, let\u2019s create a NGINX pod running as root user, as shown in the YAML block below.<\/p>\n
    kubectl apply -f - <<EOF\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n\u00a0 name: nginx\r\nspec:\r\n\u00a0 containers:\r\n\u00a0 - name: nginx\r\n\u00a0\u00a0\u00a0 image: nginx\r\n\u00a0\u00a0\u00a0 securityContext:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 runAsNonRoot: false\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 runAsUser: 0\r\nEOF<\/pre>\n
    \"\"
    Image – Create a NGINX pod running as root user<\/figcaption><\/figure>\n
    As shown above, the pod creation fails as it contains the runAsUser:0<\/code> in the above code snippet. This is one of the best security practices where running pods as root should not be allowed.<\/p>\n
    Now that we have seen how to block root access, let’s go to next demo on allowing pod to use the specific port#<\/p>\n
    Demonstration on allowing pod to use the port 443 only<\/h2>\n
    Using admission controllers, a Kubewarden rule can be enforced to use specific port only. Below sample policy requires applications to run only on 443 port.<\/p>\n
    kubectl apply -f - <<EOF\r\napiVersion: policies.kubewarden.io\/v1alpha2\r\nkind: ClusterAdmissionPolicy\r\nmetadata:\r\n\u00a0 name: psp-hostnamespaces\r\nspec:\r\n\u00a0 module: registry:\/\/ghcr.io\/kubewarden\/policies\/host-namespaces-psp:v0.1.2\r\n\u00a0 rules:\r\n\u00a0\u00a0\u00a0 - apiGroups:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 - \"\"\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 apiVersions:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 - v1\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 resources:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 - pods\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 operations:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 - CREATE\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 - UPDATE\r\n\u00a0 mutating: false\r\n\u00a0 settings:\r\n\u00a0\u00a0\u00a0 allow_host_ipc: false\r\n\u00a0\u00a0\u00a0 allow_host_pid: false\r\n\u00a0\u00a0\u00a0 allow_host_ports:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 - min: 443\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 max: 443\r\n\u00a0\u00a0\u00a0 allow_host_network: false\r\nEOF<\/pre>\n
    Let\u2019s create the following policy using kubectl apply command<\/p>\n
    \"\"
    Image – Create the policy<\/figcaption><\/figure>\n
    Now that policy has been created, let\u2019s create a NGINX pod running on port# 80, as shown in the YAML block below.<\/p>\n
    kubectl apply -f - <<EOF\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n\u00a0 name: nginx\r\nspec:\r\n\u00a0 containers:\r\n\u00a0 - name: nginx\r\n\u00a0\u00a0\u00a0 image: nginx\r\n\u00a0\u00a0\u00a0 imagePullPolicy: IfNotPresent\r\n\u00a0\u00a0\u00a0 ports:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 - containerPort: 80\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 hostPort: 80\r\n\u00a0 - name: sleeping-sidecar\r\n\u00a0\u00a0\u00a0 image: alpine\r\n\u00a0\u00a0\u00a0 command: [\"sleep\", \"1h\"]\r\nEOF<\/pre>\n
    \"\"
    Image – Create a NGINX pod running on port# 80<\/figcaption><\/figure>\n
    As shown above, the pod creation fails as it is running on port# 80<\/code>. You can customize this policy to allow other or different ports that you trust.<\/p>\n
    Cleanup<\/h2>\n
    Remove the remove the Kubewarden resources created by uninstalling the helm charts as follow:<\/p>\n
    helm uninstall --namespace kubewarden kubewarden-defaults\r\n\r\nhelm uninstall --namespace kubewarden kubewarden-controller\r\n\r\nhelm uninstall --namespace kubewarden kubewarden-crds<\/pre>\n
    Once the helm charts have been uninstalled, you can remove the Kubernetes namespace that was used to deploy the Kubewarden stack:<\/p>\n
    kubectl delete namespace kubewarden<\/code><\/p>\n
    Conclusion<\/h2>\n
    PaC solutions such as Kubewarden makes it simple and easy to do policy management on your EKS cluster, more flexible than PSS and also provide guardrails to guide cluster users, prevent unwanted behaviors, through prescribed and automated controls.<\/p>\n
    References<\/strong><\/p>\n
    https:\/\/docs.kubewarden.io<\/a><\/p>\n
    https:\/\/github.com\/kubewarden\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
    According to Red Hat’s 2022 State of Kubernetes Security Report, respondents stated that exposures due to misconfigurations in their container and Kubernetes environments (46%) is nearly three times the level of concern over attacks (16%), with vulnerabilities as the second-leading cause of worry (28%). Important settings, such as role-based access control (RBAC) and security contexts, […]<\/p>\n","protected":false},"author":2,"featured_media":1031,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"nf_dc_page":"","_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[311],"tags":[627,628],"class_list":["post-7416","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-kubernetes","tag-kubewarden","tag-pod-security-policies"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2017\/11\/kubernetes.jpg?fit=722%2C612&ssl=1","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p9fbQS-1VC","jetpack-related-posts":[{"id":5757,"url":"https:\/\/www.upnxtblog.com\/index.php\/2020\/10\/13\/10-best-practices-worth-implementing-to-adopt-kubernetes\/","url_meta":{"origin":7416,"position":0},"title":"Kubernetes Adoption in 2024: Key Statistics","author":"Karthik","date":"October 13, 2020","format":false,"excerpt":"We already know that\u00a0Kubernetes is the No. 1 orchestration platform for container-based applications, automating the deployment and scaling of these apps, and streamlining maintenance operations. However, Kubernetes comes with its own complexity challenges. So how can an enterprise take advantage of containerization to tackle complexity and not end up with\u2026","rel":"","context":"In "Kubernetes Guides"","block_context":{"text":"Kubernetes Guides","link":"https:\/\/www.upnxtblog.com\/index.php\/category\/kubernetes\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2020\/10\/Big-Idea.jpg?fit=770%2C330&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2020\/10\/Big-Idea.jpg?fit=770%2C330&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2020\/10\/Big-Idea.jpg?fit=770%2C330&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2020\/10\/Big-Idea.jpg?fit=770%2C330&ssl=1&resize=700%2C400 2x"},"classes":[]},{"id":4547,"url":"https:\/\/www.upnxtblog.com\/index.php\/2019\/12\/09\/implementing-policies-in-kubernetes\/","url_meta":{"origin":7416,"position":1},"title":"Implementing Policies in Kubernetes","author":"Karthik","date":"December 9, 2019","format":false,"excerpt":"Kubernetes, as we know, coordinates a highly available cluster of computers that are connected to work as a single unit. Kubernetes contains a number of abstractions that allow deployment of containerized applications to the cluster without attaching them to individual machines. In short, Kubernetes is - Portable: public, private, hybrid,\u2026","rel":"","context":"In "Kubernetes Guides"","block_context":{"text":"Kubernetes Guides","link":"https:\/\/www.upnxtblog.com\/index.php\/category\/kubernetes\/"},"img":{"alt_text":"kubernetes logo","src":"https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2017\/11\/kubernetes.jpg?fit=722%2C612&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2017\/11\/kubernetes.jpg?fit=722%2C612&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2017\/11\/kubernetes.jpg?fit=722%2C612&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2017\/11\/kubernetes.jpg?fit=722%2C612&ssl=1&resize=700%2C400 2x"},"classes":[]},{"id":7300,"url":"https:\/\/www.upnxtblog.com\/index.php\/2023\/09\/20\/securing-kubernetes-workloads-with-opa-opa-gatekeeper-in-amazon-eks\/","url_meta":{"origin":7416,"position":2},"title":"Top Kubernetes Security Best Practices: Securing Kubernetes Workloads with OPA & OPA Gatekeeper in Amazon EKS","author":"Karthik","date":"September 20, 2023","format":false,"excerpt":"Introduction As the adoption of container orchestration platforms like Kubernetes increases, so does the need for robust security measures. Open Policy Agent (OPA) and OPA Gatekeeper are powerful tools that help enforce policy-based security and governance in Kubernetes clusters. In this blog post, we will explore what OPA and OPA\u2026","rel":"","context":"In "Kubernetes Guides"","block_context":{"text":"Kubernetes Guides","link":"https:\/\/www.upnxtblog.com\/index.php\/category\/kubernetes\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2023\/08\/opa-gatekeeper-k8s.png?fit=840%2C480&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2023\/08\/opa-gatekeeper-k8s.png?fit=840%2C480&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2023\/08\/opa-gatekeeper-k8s.png?fit=840%2C480&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2023\/08\/opa-gatekeeper-k8s.png?fit=840%2C480&ssl=1&resize=700%2C400 2x"},"classes":[]},{"id":3719,"url":"https:\/\/www.upnxtblog.com\/index.php\/2019\/04\/12\/cloud-native-computing-foundation-adopts-cri-o-container-runtimetutorial\/","url_meta":{"origin":7416,"position":3},"title":"Cloud Native Computing Foundation adopts CRI-O container runtime+tutorial","author":"Karthik","date":"April 12, 2019","format":false,"excerpt":"CNCF team has voted to accept CRI-O as an incubation-level hosted project. CRI-O was created by Red Hat and it is an implementation of the Kubernetes Container Runtime Interface\u00a0(CRI) designed to enable the use of\u00a0Open Container Initiative (OCI) compatible runtime. In this article, let us look at key features\/components, how\u2026","rel":"","context":"In "Kubernetes Guides"","block_context":{"text":"Kubernetes Guides","link":"https:\/\/www.upnxtblog.com\/index.php\/category\/kubernetes\/"},"img":{"alt_text":"CRI-O container runtime","src":"https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2019\/04\/cri-0.jpg?fit=606%2C247&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2019\/04\/cri-0.jpg?fit=606%2C247&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2019\/04\/cri-0.jpg?fit=606%2C247&ssl=1&resize=525%2C300 1.5x"},"classes":[]},{"id":4962,"url":"https:\/\/www.upnxtblog.com\/index.php\/2020\/04\/15\/what-are-the-key-kubernetes-metrics-that-you-have-to-monitor\/","url_meta":{"origin":7416,"position":4},"title":"What are the key Kubernetes metrics that you have to monitor ?","author":"Karthik","date":"April 15, 2020","format":false,"excerpt":"We have already looked at BEST Kubernetes monitoring tools, with the increasing adoption of containers and microservices in the enterprises, monitoring utilities have to handle more services and server instances than ever before. Kubernetes environments vary from deployment to deployment, but they generally have a handful of key components, resources,\u2026","rel":"","context":"In "Kubernetes Guides"","block_context":{"text":"Kubernetes Guides","link":"https:\/\/www.upnxtblog.com\/index.php\/category\/kubernetes\/"},"img":{"alt_text":"kubernetes logo","src":"https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2017\/11\/kubernetes.jpg?fit=722%2C612&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2017\/11\/kubernetes.jpg?fit=722%2C612&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2017\/11\/kubernetes.jpg?fit=722%2C612&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2017\/11\/kubernetes.jpg?fit=722%2C612&ssl=1&resize=700%2C400 2x"},"classes":[]},{"id":3061,"url":"https:\/\/www.upnxtblog.com\/index.php\/2018\/10\/24\/3-alternative-kubernetes-container-runtimes\/","url_meta":{"origin":7416,"position":5},"title":"3 Alternative Kubernetes container runtimes","author":"Karthik","date":"October 24, 2018","format":false,"excerpt":"Container runtime is the software that is responsible for running containers. To understand better, let us look at the typical Kubernetes cluster, its comprised of a master node and a set of slave nodes. If you're looking for quickstart on basic understanding of Kubernetes concepts, please refer earlier posts for\u2026","rel":"","context":"In "Kubernetes Guides"","block_context":{"text":"Kubernetes Guides","link":"https:\/\/www.upnxtblog.com\/index.php\/category\/kubernetes\/"},"img":{"alt_text":"kubernetes logo","src":"https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2017\/11\/kubernetes.jpg?fit=722%2C612&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2017\/11\/kubernetes.jpg?fit=722%2C612&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2017\/11\/kubernetes.jpg?fit=722%2C612&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/www.upnxtblog.com\/wp-content\/uploads\/2017\/11\/kubernetes.jpg?fit=722%2C612&ssl=1&resize=700%2C400 2x"},"classes":[]}],"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/www.upnxtblog.com\/index.php\/wp-json\/wp\/v2\/posts\/7416","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.upnxtblog.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.upnxtblog.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.upnxtblog.com\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.upnxtblog.com\/index.php\/wp-json\/wp\/v2\/comments?post=7416"}],"version-history":[{"count":7,"href":"https:\/\/www.upnxtblog.com\/index.php\/wp-json\/wp\/v2\/posts\/7416\/revisions"}],"predecessor-version":[{"id":7436,"href":"https:\/\/www.upnxtblog.com\/index.php\/wp-json\/wp\/v2\/posts\/7416\/revisions\/7436"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.upnxtblog.com\/index.php\/wp-json\/wp\/v2\/media\/1031"}],"wp:attachment":[{"href":"https:\/\/www.upnxtblog.com\/index.php\/wp-json\/wp\/v2\/media?parent=7416"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.upnxtblog.com\/index.php\/wp-json\/wp\/v2\/categories?post=7416"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.upnxtblog.com\/index.php\/wp-json\/wp\/v2\/tags?post=7416"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}