Conjur - Connect from AWS to on premise server - credential management required


Please see my use case below and help me to select the API calls or services to implement a solution for this.

I have a Lambda solution in our AWS account which need to access the Rest APIs created in PeopleSoft which is hosted in our on premise server. I would like to have a security solution to access the API without keeping my credentials in AWS. I prefer a dynamic credentials (password or token) to access the PeopleSoft APIs.

Is Conjur helps on this.

I am able to build a Conjur server in our AWS account as given in the ‘Conjur-Open Source’ documentation. I am not sure what could be the next step to implement a solution for the use case explained above.


Hi Ramesh, great question. I believe Conjur open source can support hybrid environments like this, but we have passed this along to our technical team and hopefully someone will be able to get back to you relatively soon. They may need some more details on your use case. Chris

@ramesh.balakrishnan: We do not support Dynamic Secrets in the traditional sense. We can store the PeopleSoft API token or key and provide it to you “just-in-time” through various means. Would this be sufficient for your use case?

@joe.garcia Thanks for the reply. As per your suggestion Peoplesoft team need to provide a static user id and password, that can be stored in Conjur and the AWS service can connect to Conjur to get the userid and password. and I understood that we cannot implement the password rotation for this. Correct.

This is absolutely something Conjur can assist with.

The next step after setting up Conjur is to define a policy and store your secret(s).

Starting with this section of our quick start tutorial and following through will help you get a sense for how to accomplish that.

You’ll want to create a !host identity within that policy that will generate a Host ID & API Key for your AWS Lambda function. Then, encrypt the Host ID & API Key as environment variables in the Lambda function configuration so it can use them when triggered.

Once that’s done and you want to test retrieving the secrets, our API documentation can be referred to in order to retrieve the secrets for PeopleSoft that you defined in your policy.

Hi Joe,
Thanks for the info. I will try this.

I am still have a question about the password. Is it rotatable or not. If it is rotatable, how Peoplesoft can connect to validate the new passwords?

Also, our concern is about keeping credentials in AWS. So could you please let me know the difference between keeping the PeopleSoft id and password in our Lambda and keeping the host id and key of Conjur in our Lambda to get the password from Conjur.


We do not have a rotator for PeopleSoft API keys. So it wouldn’t be able to be managed, just stored.

Regarding keeping the Host ID and API Key out of AWS, you can utilize our AWS IAM Authenticator instead. This doesn’t require any secrets to be kept in AWS. You can check it out here:

That should ensure AWS is truly secretless. Sorry, I missed that point in your original request.

1 Like

Thank you Joe.

Is the Conjur password manager where we need to keep the PeopleSoft credentials is in your AWS environment or we can build the Conjur server in our environment?

I will try the solutions you provided and update you.


Hi Ramesh,

You can deploy conjur in AWS or within your own environment. Which ever you prefer.
If your lambda function is using python you can use this module to help you authenticate to conjur via our authn-iam authentication service.

Of coarse you will have to configure & enable the authn-iam authentication service on the conjur side. Information about this can be found here:


1 Like