Question

Can I have NET_ADMIN capability in Kubernetes?

Posted May 21, 2019 1k 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?

Add a comment
csantos
By:
csantos
Add a comment

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

1 answer
snormoredo May 21, 2019

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 √
Reply Report
  • csantos May 22, 2019

    I checked again now and only NET_ADMIN fails. My version is 1.14.1-do.2.

    Reply Report
    • snormoredo May 22, 2019

      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.

      Reply Report
      • csantos May 22, 2019

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

        Reply Report
        • snormoredo May 22, 2019

          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 :)

          Reply Report
Submit an Answer

Related

Looking for something else?

Ask a new question Search for more help