As we reach the end of September 2024, ThreadFix version 3.x on-premises has officially reached its End-of-Life. Therefore, there is no longer support or updates for this version of the product. We have fully transitioned our product and development teams to focus ThreadFix SaaS and migrating all customers over from the on-premises versions. Our Customer Success and Support teams are here to help you in migrating to ThreadFix SaaS and maximizing the value you see from this improved offering from Coalfire. This is the next phase of ThreadFix and our team is looking forward to continuing to support you on this journey.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

📙 You will learn

How to check Kubernetes permissions for ThreadFix and how to install ThreadFix as a less privileged user.

Prerequisites

Audience: IT Professional
Difficulty: Basic
Time needed: Approximately 10 minutes
Tools required: N/A

The default installation of ThreadFix on Kubernetes requires 'cluster-admin' or equivalent privileges.

ThreadFix Helm Resources

When installing ThreadFix via helm, the following resources are used:

  • clusterrole*

  • clusterrolebinding*

  • configmap

  • customresourcedefinition**

  • deployment

  • ingress

  • job

  • networkpolicy

  • persistentvolumeclaim

  • poddisruptionbudget

  • role

  • rolebinding

  • secret

  • service

  • serviceaccount

  • statefulset

* These resources are optional.

** This resource can be installed by a separate user.

Checking Permissions with Script

The easiest way to check Kubernetes permissions for ThreadFix is use the check-k8s-permissions.sh script above.

  1. Download the check-k8s-permissions.sh script linked above

  2. Set the namespace to be used for ThreadFix (replace <namespace> with the appropriate value)

    TF_NAMESPACE=<namespace>
  3. Execute the script

    bash ./check-k8s-permissions.sh -n $TF_NAMESPACE
  4. Review the output of the script and take any corrective actions recommended

Manually Checking Permissions

Alternatively, access to create these resources can be manually checked with the 'can-i' function of Kubernetes. For example, to check if the current user has permission to create a 'clusterrole' resource, run the following:

kubectl auth can-i create clusterroles

The command will return 'yes' if the current user has sufficient permissions or 'no' if the current user does not have sufficient permissions to create the named resource. Perform the 'can-i' for each of the resources listed above.

If the command returns 'no' for 'clusterrole' and 'clusterrolebinding', follow the Installing without ClusterRole and ClusterRoleBinding Permissions guide . If the command returns 'no' for 'customerresourcedefinition', an administrator may apply these resources by following the Pre-Installing Custom Resource Definitions Guide section. If CustomResourceDefinitions cannot be applied, ThreadFix cannot be installed

If any of the other resources return ‘no’, the user will not be able to install ThreadFix.

Table of contents

  • No labels