<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Psp on The IT Hollow</title>
    <link>https://theithollow.com/tags/psp/</link>
    <description>Recent content in Psp on The IT Hollow</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 19 Nov 2019 15:05:04 +0000</lastBuildDate>
    <atom:link href="https://theithollow.com/tags/psp/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Kubernetes - Pod Security Policies</title>
      <link>https://theithollow.com/2019/11/19/kubernetes-pod-security-policies/</link>
      <pubDate>Tue, 19 Nov 2019 15:05:04 +0000</pubDate>
      <guid>https://theithollow.com/2019/11/19/kubernetes-pod-security-policies/</guid>
      <description>&lt;p&gt;Securing and hardening our Kubernetes clusters is a must do activity. We need to remember that containers are still just processes running on the host machines. Sometimes these processes can get more privileges on the Kubernetes node than they should, if you don&amp;rsquo;t properly setup some pod security. This post explains how this could be done for your own clusters.&lt;/p&gt;
&lt;h2 id=&#34;pod-security-policies---the-theory&#34;&gt;Pod Security Policies - The Theory&lt;/h2&gt;
&lt;p&gt;Pod Security policies are designed to limit what can be run on a Kubernetes cluster. Typical things that you might want to limit are: pods that have privileged access, pods with access to the host network, and pods that have access to the host processes just to name a few. Remember that a container isn&amp;rsquo;t as isolated as a VM so we should take care to ensure our containers aren&amp;rsquo;t adversely affecting our nodes&amp;rsquo;s health and security.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Path Selection Policy with ALUA</title>
      <link>https://theithollow.com/2012/03/08/path-selection-policy-with-alua/</link>
      <pubDate>Thu, 08 Mar 2012 13:58:05 +0000</pubDate>
      <guid>https://theithollow.com/2012/03/08/path-selection-policy-with-alua/</guid>
      <description>&lt;p&gt;It&amp;rsquo;s important to understand how VMware ESXi servers handle connections to their associated storage arrays.&lt;/p&gt;
&lt;p&gt;If we look specifically with fibre channel fabrics, we have several multipathing options to be considered.
There are three path selection policy (PSP) plugins that VMware uses natively to determine the I/O channel that data will travel over to the storage device.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Fixed Path&lt;/li&gt;
&lt;li&gt;Most Recently Used (MRU)&lt;/li&gt;
&lt;li&gt;Round Robin (RR)&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;Let&amp;rsquo;s look at some examples of the three PSPs we&amp;rsquo;ve mentioned and how they behave.  The definitions come from the vSphere 5 storage guide found below.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
