<p>I would like to read state of K8s using µK8s, but I don't want to have rights to modify anything. How to achieve this?</p>
<p>The following will give me full access:</p>
<pre><code>microk8s.kubectl  Insufficient permissions to access MicroK8s. You can either try again with sudo or add the user digital to the 'microk8s' group:

   sudo usermod -a -G microk8s digital    sudo chown -f -R digital ~/.kube

The new group will be available on the user's next login.
</code></pre>

digital_infinity
<blockquote>
<p>on Unix/Linux we can just set appropriate file/directory access
permission - just <code>rx</code>, decrease shell limits (like max memory/open
file descriptors), decrease process priority (<code>nice -19</code>). We are
looking for similar solution for K8S</p>
</blockquote>
<p>This kind of solutions in Kubernetes are handled via <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/" rel="nofollow noreferrer">RBAC</a> (Role-based access control).  RBAC prevents unauthorized users from viewing or modifying the cluster state. Because the API server exposes a REST interface, users perform actions by sending HTTP requests to the server. Users authenticate themselves by including credentials in the request (an authentication token, username and password, or a client certificate).</p>
<p>As for REST clients you get <code>GET</code>, <code>POST</code>, <code>PUT</code>,<code>DELETE</code> etc. These are send to specific URL paths that represents specific REST API resources (Pods, Services, Deployments and so).</p>
<p>RBAC auth is configured with two groups:</p>
<ul>
<li>Roles and ClusterRoles - this specify which actions/verbs can be performed</li>
<li>RoleBinding and ClusterRoleBindings - this bind the above roles to a user, group or service account.</li>
</ul>
<p>As you might already find out the <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/#clusterrole-example" rel="nofollow noreferrer">ClusterRole</a> is the one your might be looking for. This will allow to restrict specific user or group against the cluster.
In the example below we are creating <code>ClusterRole</code> that can only list pods. The namespace is omitted since ClusterRoles are not namepsaced.</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-viewer
rules:
- apiGroups: [&quot;&quot;]
  resources: [&quot;pods&quot;]
  verbs: [&quot;list&quot;]
</code></pre>
<p>This permission has to be bound then via <code>ClusterRoleBinding</code> :</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the &quot;manager&quot; group to list pods in any namespace.
kind: ClusterRoleBinding
metadata:
  name: list-pods-global
subjects:
- kind: Group
  name: manager # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-viewer
  apiGroup: rbac.authorization.k8s.io
</code></pre>
<p>Because you don't have the enough permissions on your own you have to reach out to appropriate person who manage those to create user for you that has the <code>ClusterRole: View</code>. View role should be predefined already in cluster ( <code>kubectl get clusterrole view</code>)</p>
<p>If you wish to read more <a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/" rel="nofollow noreferrer">Kubernetes docs</a> explains well its whole concept of authorization.</p>
