The security of the Pliant platform is of the utmost importance.
Passwords for local Pliant users are stored using a non-reversible salted hash (bcrypt). This is the default password encoder in the Spring Security library, part of the widely used Spring Framework.
Pliant also supports using third party identity providers (IdP) for authentication using LDAP, SAML, or RADIUS protocols. Passwords for IdP authenticated users are never cached nor stored on Pliant, and communications can be configured to use the TLS cryptographic protocol for encryption in network transit.
Pliant supports a granular role based access scheme. Pliant administrators create roles to delegate access at the workflow, vendor integration, authKey, and even action block level.
This allows for the creation of users that can perform only limited functions, even when the underlying vendor APIs are “all or nothing” access, or allows users who can run a workflow but not make edits. A single user can be assigned multiple roles.
Pliant separates authentication logic from workflow logic using authKeys. An authKey specifies the connection details for a given system (for example, vCenter FQDN, username, and password). The details of the authKey are encrypted and stored at creation time, and afterwards are not readable by users in the system. The only time the authKey is decrypted is during workflow execution for use in the Pliant worker.
In Pliant workflows, authKeys are represented by name “tags” which conceal the credentials while allowing users to build automation.
Sensitive data within Pliant, including API keys, authKeys, worker group shared secrets, and configuration information, is stored in encrypted database fields. The data is stored using AES256 encryption with key material derived from a 2048 bit private key. The decryption key is not stored with the database.
On hosted production Pliant deployments, Pliant uses the cloud-native encryption on all disk storage, so all at rest Pliant data is encrypted. For premise installations, Pliant highly recommends the use of encrypting disks in the underlying storage system.
Internal (pod to pod) network traffic within Pliant is isolated from the network at large. Pliant services are only available via a reverse proxy pod, delivering connectivity via HTTPS and other encrypted protocols
Pliant Remote workers communicate with the Pliant API using HTTPS, so any sensitive data is encrypted in flight. Communications with the Pliant Message Bus are also encrypted, using the AMQPS protocol. Remote workers authenticate to the parent Pliant instance using a pre-shared key.
Get a jumpstart on building efficiencies into your organization.
Contact our team, we’ll discuss