Built-in Accounts Overview
Focus
Focus
Next‑Gen Trust Security

Built-in Accounts Overview

Table of Contents

Built-in Accounts Overview

Use built-in accounts to authenticate and manage access for non-user accounts such as APIs, applications, and services, collectively referred to collectively as machines.
These accounts are designed to provide a secure and efficient way to handle machine-based interactions without the need for traditional user credentials.

Types of Built-in Accounts

When setting up a new built-in account, you can select from several predefined use cases, each tailored to specific operational needs within the CyberArk environment.
Example use case:
Using built-in accounts instead of user accounts to authenticate helps you maintain access to machines previously managed by employees who leave your organization. Suppose you had a colleague named Jones who managed your Workload Identity Manager deployments and another application running on AWS. Jones used his own user accounts (usernames and passwords) to authenticate to those machines. But he decides to move to another team.
After Jones leaves, nobody on your team can authenticate to Jones' machines. However, if Jones had set up built-in accounts before he left the organization, you and your team would have had uninterrupted access.
Here's a brief overview of each available built-in accounts:

Workload Identity Management

  • Purpose: Allows a workload identity issuer to connect to the Control Plane.
  • Tool: CyberArk Workload Identity Manager (Workload Identity Manager)
  • Use case: Ideal for scenarios where a dedicated Workload Identity Manager application needs secure and continuous interaction with Next-Gen Trust Security without manual authentication.

Discovery Agent

  • Purpose: Allows a Palo Alto Networks Discovery Agent to connect to the Certificate Manager for Kubernetes.
  • Tool: Discovery Agent for CyberArk Certificate Manager in Kubernetes and OpenShift Environments (Discovery Agent)
  • Use case: Used primarily in environments where Kubernetes clusters must autonomously verify and manage certificates or configurations directly through Next-Gen Trust Security.

Certificate Manager - Self-Hosted

  • Purpose: Enables your self-hosted instance to connect to the Certificate Manager for Kubernetes.
  • Tool: Certificate Manager - Self-Hosted
  • Use case: Enables Certificate Manager - Self-Hosted to integrate with Next-Gen Trust Security. The Kubernetes Discovery Job in Certificate Manager - Self-Hosted retrieves certificates discovered using CyberArk Certificate Manager for Kubernetes and pulls them into the Certificate Manager - Self-Hosted inventory. This provides Certificate Manager - Self-Hosted customers a single view for all certificates.
  • Note: This account must have the Venafi TLS Protect for Datacenter scope.

OCI Registry

  • Purpose: Allows you to pull artifacts such as enterprise components for Kubernetes from the protected Palo Alto Networks registry.
  • Use case: Essential for automated systems that require frequent access to update or pull configurations and components from the registry without human intervention.

cert-manager Enterprise Issuer

  • Purpose: Allows cert-manager to request certificates from Control Plane.
  • Tool: cert-manager with Enterprise Issuer component
  • Authentication: Uses Workload Identity Federation with credentials from OIDC providers
  • Use case: Enables cert-manager deployed in Kubernetes clusters to seamlessly request and manage certificates from Next-Gen Trust Security using workload identity authentication.

Custom API Integration

  • Purpose: Securely authenticate with Next-Gen Trust Security APIs using Workload Identity Federation.
  • Use case: Supports scenarios where machines require a scalable and secure authentication mechanism to access APIs without traditional API keys. Learn more

Code Sign Manager

  • Purpose: Allow the Code Sign Client to authenticate to Next-Gen Trust Security.
  • Tool: Code Sign Client
  • Use case: Enables the Code Sign Client to authenticate to Next-Gen Trust Security. Once authenticated, the Code Sign Client can sync signing key and certificate references to the signing workstation. This allows developers, applications, CI/CD pipelines, or other automated systems to securely sign using keys protected by Next-Gen Trust Security. Learn more

Scanafi

  • Purpose: Allows Scanafi to discover and report machine identities to Control Plane.
  • Tool: Scanafi utility
  • Use case: Use Scanafi utility to manually run a Basic Discovery service for performing certificate discovery in your network. Learn more

Creating Built-in Accounts

Creating a built-in account involves a few straightforward steps:
  1. Select the use case: Choose the type of built-in account based on your desired use case.
  2. Configure details: Provide necessary details specific to the chosen built-in account type.
  3. Set credentials: Depending on the built-in account, you might need to supply credentials like API keys or configure token-based authentication.
To get started, select the built-in account that best matches your use case: