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 setup.tmpl
, as
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
authentication.
Solution¶
The drpcli
client can use two primary modes of authentication to
provide the necessary details to access and use the DRP Endpoint API.
They are:
- 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.
Using setup.tmpl
¶
The Template named setup.tmpl
is designed to be used with Bash shell
scripts in Workflow. It will setup the appropriate Shell variables for
the 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:
RS_ENDPOINT="<https://drp.example.com:8092>"
RS_TOKEN="...long string with token here..."
RS_UUID="...current machine's UUID here..."
These variables can also be optionally used in the script if needed.
Note
The 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
with the 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 Information¶
Additional resources and information related to this Knowledge Base article.
See Also¶
- rs_faq_drpcli
- rs_model_template expansion functions
- rs_data_render
- rs_data_claim System for elevated privilege access
- Knowledge Basse detailing
What_are_ExtraClaims
Versions¶
All DRP Versions
Keywords¶
drpcli, rs_endpoint, rs_token, rs_username, rs_password, rs_uuid, template, rendering, api