Can I have NET_ADMIN capability in Kubernetes?

May 21, 2019 499 views
Kubernetes

Linkerd is in Digital Ocean Kubernetes’ product page (Use Kubernetes Tooling). However, when I run “linkerd check –pre”, I get:

pre-kubernetes-capability
-------------------------
× has NET_ADMIN capability
    found 2 PodSecurityPolicies, but none provide NET_ADMIN
    see https://linkerd.io/checks/#pre-k8s-cluster-net-admin for hints

Is it possible to install Linkerd in DO managed Kubernetes?

1 Answer
snormoredo May 21, 2019
Accepted Answer

Hi @csantos,

You should be able to use Linkerd today, our DOKS clusters do have NET_ADMIN capability by default.

What version is the cluster that you created? Are the other checks passing, did you only paste the failure?

I confirmed on 3 of our latest patch versions for 1.12, 1.13, and 1.14. Using https://linkerd.io/2/getting-started/ after spinning up a DOKS cluster I am seeing all pre-checks pass:

$ linkerd check --pre
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API

kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version

pre-kubernetes-setup
--------------------
√ control plane namespace does not already exist
√ can create Namespaces
√ can create ClusterRoles
√ can create ClusterRoleBindings
√ can create CustomResourceDefinitions
√ can create ServiceAccounts
√ can create Services
√ can create Deployments
√ can create ConfigMaps

pre-kubernetes-capability
-------------------------
√ has NET_ADMIN capability

linkerd-version
---------------
√ can determine the latest version
√ cli is up-to-date

Status check results are √

After installing linkerd manifests I’m seeing all checks pass:

$ linkerd check
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API

kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version

linkerd-existence
-----------------
√ control plane namespace exists
√ controller pod is running
√ can initialize the client
√ can query the control plane API

linkerd-api
-----------
√ control plane pods are ready
√ control plane self-check
√ [kubernetes] control plane can talk to Kubernetes
√ [prometheus] control plane can talk to Prometheus
√ no invalid service profiles

linkerd-version
---------------
√ can determine the latest version
√ cli is up-to-date

control-plane-version
---------------------
√ control plane is up-to-date
√ control plane and cli versions match

Status check results are √
  • I checked again now and only NET_ADMIN fails. My version is 1.14.1-do.2.

    • I just confirmed on a 1.14.1-do.2 cluster:

      $ linkerd check --pre
      kubernetes-api
      --------------
      √ can initialize the client
      √ can query the Kubernetes API
      
      kubernetes-version
      ------------------
      √ is running the minimum Kubernetes API version
      √ is running the minimum kubectl version
      
      pre-kubernetes-setup
      --------------------
      √ control plane namespace does not already exist
      √ can create Namespaces
      √ can create ClusterRoles
      √ can create ClusterRoleBindings
      √ can create CustomResourceDefinitions
      √ can create ServiceAccounts
      √ can create Services
      √ can create Deployments
      √ can create ConfigMaps
      
      pre-kubernetes-capability
      -------------------------
      √ has NET_ADMIN capability
      
      linkerd-version
      ---------------
      √ can determine the latest version
      √ cli is up-to-date
      
      Status check results are √
      

      What’s your cluster UUID? You can grab this from doctl or from the URL in your DO cloud panel.

      • Maybe this one: 4ac06613-6211-494a-b6be-38e5af7fd2a0

        • Ok I see the issue now, thanks for the additional data.

          It looks like linkerd check --pre makes this assumption (https://github.com/linkerd/linkerd2/pull/2421):

          the presense of PodSecurityPolicies in the cluster means the PodSecurityPolicy admission controller is installed. If the admission controller is not installed, but PSPs exists that restrict NET_ADMIN, linkerd check will incorrectly report the user does not have that capability.

          I’ve been running linkerd check --pre on empty clusters, meaning there are no PodSecurityPolicies in it, but your cluster has a couple PSPs created by grafana. I was able to reproduce what you’re seeing by running on one of my clusters with grafana-created PSPs as well.

          The reason this assumption is not valid is that the presence of the PSP CRD does not actually imply that the PSP admission controller is enabled. We do not enable the PSP admissions controller by default in DOKS clusters, as that would restrict deployment of any workloads until an initial PSP is added.

          You can see the checks pass by running it on a cluster without any PSPs, or by adding a dummy PSP that allows NET_ADMIN since the linkerd check logic expects this if any PSPs exist. I’d recommend the former.

          Rest assured though, you can run linkerd on DOKS :)

          • Thank you for the awesome support! I installed linkerd and its post-install check was successful.

Have another answer? Share your knowledge.