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
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
Use case: Supports scenarios where machines require a scalable and secure authentication mechanism to access APIs without traditional API keys.
Learn more