Using 'drpcli' in Workflow
This article explains how to use the
drpcli client binary in workflow
Tasks or Templates. The client requires authentication to the DRP
Endpoint. The authentication information can be generated on the fly by
the DRP Endpoint, and rendered in Templates for Tasks to use.
This article explains how to use the RackN provided
well as using Golang Template rendering constructs to build up the
appropriate values needed.
This method can be used in regular shell scripts as Tasks, within Context Container usage, or any other place where the template rendering can be used to automatically set up access to the API services for Workflow.
This document outlines use of the Token (eg
RS_TOKEN) method for
drpcli client can use two primary modes of authentication to
provide the necessary details to access and use the DRP Endpoint API.
- Username and Password (eg "basic") authentication
- Token authentication
By default Tokens that are generated for use in Workflow are only scoped to allow changes to the Machines object. This is a security control mechanism.
The Template named
setup.tmpl is designed to be used with Bash shell
scripts in Workflow. It will setup the appropriate Shell variables for
drpcli client. This allows the
drpcli tool to be used
transparently without any options; as it will use the Shell environment
variables by default.
To use it simply add the following Template injection near the top of your task/template:
When the Template is rendered, the following Variables are set that the
drpcli client will use:
These variables can also be optionally used in the script if needed.
setup.tmpl is maintained under Templates in the DRP Community
Content pack. Refer to it for complete details on all of the environment
settings it manipulates (eg "exit on error" -
set -e, interaction
rs-debug-enable Param, etc).
Using Golang Template Rendering¶
Building up the appropriate details via Golang Template rendering is
very easy. There are several helper functions that make this easy.
Here's an example of setting Shell variables appropriately for the
drpcli client tool: This is effectively replicating what the
setup.tmpl above does.
These can be rendered as Shell variables (as shown above), or in whatever native language format your Task/Template is using.
A Note on ExtraClaims and Permissions¶
From time to time you may need to authorize Tasks with the ability to manipulate other Objects in the system besides the Machines specific Object. This can be done by providing elevated permissions via the rs_data_claim system.
These are used by setting the Task
ExtraClaims fields appropriately,
as in the following example to modify Profiles:
Note that the above ExtraClaims specifies full access to
read/write/update all Profiles on the system. This is potentially bad.
You can limit the authorization to only a specific Profile by specifying
it by Name in the
specific portion of the stanza.
Additional resources and information related to this Knowledge Base article.
- rs_model_template expansion functions
- rs_data_claim System for elevated privilege access
- Knowledge Basse detailing
All DRP Versions
drpcli, rs_endpoint, rs_token, rs_username, rs_password, rs_uuid, template, rendering, api