Model Scanner API

Model Scanner analyzes Machine Learning Models to identify malware, vulnerabilities, and integrity issues.

---

HiddenLayer Model Scanner analyzes Machine Learning Models to identify hidden cybersecurity risks and threats such as malware, vulnerabilities, and integrity issues. Its advanced scanning engine is built to analyze your machine learning models, meticulously inspecting each layer and component to detect possible signs of malicious activity, including malware, tampering, and backdoors.

Model Scanner API solution provides users with the freedom to deploy and run a model scanning tool on their infrastructure, whether it be on physical servers, cloud services, or in a secure, isolated environment without internet connectivity (air-gapped). This level of control is valuable for organizations with specific security, compliance, or operational requirements.

Model Scanner API solution is distributed as Docker images and can be run on any Docker-compatible environment. This technical document outlines the steps required to download and deploy the Model Scanner Docker images using Kubernetes orchestration tools.

The Model Scanner Installer is used to deploy the Orchestrator into your Kubernetes environment. Rather than packaging all Helm charts directly, the installer dynamically pulls the necessary components from HiddenLayer’s container registry on Quay.

As part of the deployment process, the installer sets up the Model Scanner Orchestrator, which is responsible for handling scan requests, scheduling secure, isolated batch jobs within Kubernetes to perform the scans, and collecting the results. These results are stored locally in a Redis instance, and depending on your deployment mode, may also be securely forwarded to the HiddenLayer Console.

The Model Scanner Orchestrator is the core service that handles scanning tasks and API requests. When you install Model Scanner, it’s important to understand how this component is made accessible within your environment.

Release Notes

Read the latest Model Scanner release notes.

Default Behavior

By default, the installer provisions the Orchestrator using an internal-only LoadBalancer. This means:

• It gets an IP address inside your cloud provider’s private network.
• It is not publicly accessible from the internet.
• It can only be accessed by other services inside your cloud environment or VPC.

This is a security-conscious default, ensuring that Model Scanner is not accidentally exposed.

Service Types and Network Exposure

In Kubernetes, services are used to expose applications running in the cluster. There are several service types available, including ClusterIP, NodePort, and LoadBalancer.

Model Scanner uses a combination of ClusterIP and LoadBalancer service types to manage how different components are accessed within your Kubernetes cluster.

• ClusterIP is used for the majority of internal services. This means they are only reachable from within the cluster, which improves security and limits unnecessary exposure.
• LoadBalancer is used specifically for components that need to be accessible from outside the cluster, such as the Orchestrator API. This allows your cloud provider (AWS, Azure, GCP, etc.) to automatically provision a managed load balancer.

We do not use NodePort directly in any of our service definitions.

• Kubernetes has a default setting called allocateLoadBalancerNodePorts: true, which means:

• When a service of type LoadBalancer is created, Kubernetes will also allocate a NodePort behind the scenes.

• This allows cloud load balancers that route traffic through NodePorts to function correctly.

We intentionally leave this default behavior enabled to maintain compatibility across various Kubernetes environments. Disabling NodePort allocation (allocateLoadBalancerNodePorts: false) could break connectivity in clusters where the cloud load balancer depends on NodePort access.

Key Components and Behaviors

• Job Orchestration: The Orchestrator interacts directly with the Kubernetes API to spin up ephemeral batch jobs that perform scans in isolated containers.
• Local Result Storage: Scan results are cached locally in a Redis instance, allowing for quick retrieval or forwarding, depending on the deployment mode.
• Dynamic Installer: The installer does not bundle the full Helm charts for all services. Instead, it dynamically pulls the appropriate Helm charts from HiddenLayer’s container registry on Quay , simplifying installation and ensuring you're always using the latest stable release.

RBAC and Security

To function within Kubernetes securely and with proper isolation, Model Scanner creates two distinct RBAC roles:

• Installer Role: Grants temporary, scoped permissions needed only during the setup process. This includes pulling and applying the Helm charts.
• Model Scanner Role: Grants the Orchestrator the ability to interact with the Kubernetes API to create, monitor, and clean up batch jobs used during model scans.

These roles are created and scoped appropriately to reduce security risk while enabling the orchestrator to perform its job reliably.

EXPAND to see the full RBAC role definition.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: hl-aisec-platform
rules:
  - apiGroups:
      - apps
    resources:
      - deployments
      - statefulsets
    verbs:
      - create
      - delete
      - deletecollection
      - get
      - list
      - update
      - patch
      - watch
  - apiGroups:
      - batch
    resources:
      - jobs
    verbs:
      - create
      - delete
      - deletecollection
      - get
      - list
      - update
      - patch
      - watch
  - apiGroups:
      - ""
    resources:
      - secrets
      - services
      - serviceaccounts
      - configmaps
      - persistentvolumeclaims
      - namespaces
    verbs:
      - create
      - delete
      - deletecollection
      - get
      - list
      - update
      - patch
      - watch
  - apiGroups:
      - rbac.authorization.k8s.io
    resources:
      - roles
      - rolebindings
    verbs:
      - create
      - delete
      - deletecollection
      - get
      - list
      - update
      - patch
      - watch
  - apiGroups:
      - networking.k8s.io
    resources:
      - networkpolicies
    verbs:
      - create
      - delete
      - deletecollection
      - get
      - list
      - update
      - patch
      - watch
  - apiGroups:
      - policy
    resources:
      - poddisruptionbudgets
    verbs:
      - create
      - delete
      - deletecollection
      - get
      - list
      - update
      - patch
      - watch
  - apiGroups:
      - autoscaling
    resources:
      - horizontalpodautoscalers
    verbs:
      - create
      - delete
      - deletecollection
      - get
      - list
      - update
      - patch
      - watch

End User License Agreement

Usage of this Docker Image is subject to HiddenLayer's End-User License Agreement (EULA). Before accessing or utilizing the Docker Image, please carefully review and agree to the terms and conditions outlined in the EULA provided by HiddenLayer. The EULA governs the rights, limitations, and obligations associated with the use of the Docker Image. By using the Docker Image, you indicate your acceptance of the EULA and your commitment to adhere to its provisions. If you do not agree with the terms and conditions set forth in the EULA, refrain from using the Docker Image.

Architecture and Deployment Modes

See Hybrid and Disconnected Modes for information about Model Scanner architecture and the different modes it can be deployed to.