Harness delegates are the primary utility used to achieve the successful completion of most tasks via harness. A question quite often asked are some best practices around using shared delegates for prod and non-prod.
Presently we have customers who use both shared and separate delegates for their production and non-production environments and completely depends on their use-case case as well as security requirements and mandates from their concerned security/infosec teams. Let us go over some advantages and disadvantages of both these scanrios.
Using Shared Delegates
- Easier monitoring and maintenance
- single point to provide permissions and authorization
- lesser number of overall delegates and slight cost reduction
- Single point of failure
- May get overloaded in case too many executions/deployments happen via this which may cause delay in deployments or artifact collection
- Security concern in some cases (company polices)
Using Separate Delegates for prod and non-prod
- Easier to track jobs and logs for failed executions
- If prod env needs to be segregated from non-prod network, or comply with firewall policies
- in case of some K8s deployment your SA or user might have different permissions for security reasons
- clear demarkation of which WF or pipleines on certain environments (prod) should use which delegate
- Cost may be slightly higher in case of separate hosting
- More delegates to track and maintain
- additional setup of RBAC and permissions may be required
Overall in most cases we generally prefer to have separate delegates for prod environments and share a delegate for the non-prod environment for easier tracking and security concerns. Please also refer to Scope Delegates to Harness Components and Commands - Harness.io Docs around scoping for this.