Skip to main content

Kubernetes Native

Visualize Kubernetes resources and monitor changes through queries and alerts.

Installation​

info

To use this integration, you must have a running Kubernetes cluster. This integration with JupiterOne is deployed as a pod and interacts with a Kubernetes API server.

Configuration in JupiterOne​

  1. Navigate to the Integrations tab in JupiterOne and select Kubernetes.

  2. Click New Instance to begin configuring your integration and provide the following:

    • Account Name — used to identify the Kubernetes account in JupiterOne. Ingested entities will have this value stored in tag.AccountName when the AccountName toggle is enabled.
    • Description (optional) — helps identify the integration instance.

  3. Click Create. Your instance appears in the list of Kubernetes instances.

  4. Click the name of the new instance and go to the API Keys tab.

  5. Follow the prompts to create an integration API key.

  6. Click Reveal and copy the API key.

For the Kubernetes configuration you will need:

  • The Integration API Key you just created
  • The Integration Instance ID (listed as ID in Configuration Settings)
  • Your Account ID (listed under Account Management after clicking the gear icon)

The easiest way to install and keep the integration up to date is through the published Helm chart. See the JupiterOne Helm repository for full chart documentation.

Quickstart​

helm repo add jupiterone https://jupiterone.github.io/helm-charts
helm repo update
helm install [RELEASE_NAME] jupiterone/graph-kubernetes \
  --set secrets.jupiteroneAccountId="<account-id>" \
  --set secrets.jupiteroneApiKey="<api-key>" \
  --set secrets.jupiteroneIntegrationInstanceId="<integration-instance-id>"

The Helm chart automatically creates the service account, the required RBAC Role/ClusterRole, and the RoleBinding/ClusterRoleBinding for the integration.

Configuration in Kubernetes using standard YAML​

Authentication — RBAC​

The integration runs as a Kubernetes service account that must be granted read access to the resources it ingests. It dynamically skips any resource type the service account cannot access, so you can tune permissions to match what your cluster allows.

note

The built-in view ClusterRole is not sufficient. It omits secrets, cluster-scoped RBAC resources (clusterroles, clusterrolebindings), nodes, and certificatesigningrequests, which the integration collects. Use a custom Role or ClusterRole as shown below.

Namespace-scoped access (limits ingestion to a single namespace):

  1. Create a service account: 
    kubectl create sa jupiterone-integration -n <namespace>
  2. Apply a custom Role granting read access to the required resources, then bind it: 
    kubectl apply -f role.yml
    kubectl apply -f roleBinding.yml

Cluster-wide access (ingests all namespaces and cluster-scoped resources):

  1. Create a service account: 
    kubectl create sa jupiterone-integration-cluster
  2. Apply a custom ClusterRole and ClusterRoleBinding: 
    kubectl apply -f clusterRole.yml
    kubectl apply -f clusterRoleBinding.yml

See the Helm chart RBAC templates for reference Role and ClusterRole definitions that match the integration's full resource requirements.

note

If you use a different service account name or namespace, update the names consistently across all YAML files and kubectl commands.

Secrets​

The integration reads your JupiterOne credentials from Kubernetes Secrets. Create the secret with base64-encoded values:

kubectl apply -f createSecret.yml

Deploying​

Deploy the integration as a Kubernetes CronJob:

  • Namespace-scoped access:

    kubectl apply -f cronjobNamespace.yml

  • Cluster-wide access:

    kubectl apply -f cronjobCluster.yml

Debugging​

  • Check whether the CronJob was created:

    kubectl get cronjob

  • Check whether the CronJob has spawned jobs:

    kubectl get job

  • View pod logs:

    kubectl logs --selector job-name=<job-name>

Uninstall​

kubectl delete cronjob <name>
kubectl delete serviceaccount <serviceaccount> -n <namespace>
kubectl delete clusterrolebinding <clusterrolebinding>
kubectl delete clusterrole <clusterrole>

Upgrading​

Reapply any changed resource manifest:

kubectl apply -f resourceFile.yaml

Telemetry and Diagnostics​

The Helm chart and vanilla Kubernetes YAML manifests include the OpenTelemetry Collector and FluentBit, with FluentBit forwarding container logs into the OpenTelemetry Collector. To forward telemetry to your own systems (CloudWatch, Prometheus, etc.), configure the collector to point to them and update the manifests.

Next steps​

Now that your integration instance has been configured, it will begin running on the polling interval you provided, populating data within JupiterOne. Continue on to our Instance management guide to learn more about working with and editing integration instances.