Incorporating Conjur in Integration Test Suite

Hello. I am currently working on a PoC incorporating support for pulling secret values from Conjur into the commercial version of sensu go: https://sensu.io/. So far things are going well, and we have some basic functionality working.

I would really appreciate some guidance on what might be an appropriate way to incorporate a Conjur deployment into our testing suite. Ideally I believe I’d like our test suite to create (and tear down) isolated accounts with some arbitrary policy for each test case.The issue I am struggling with is that it feels awkward to automate account creation and get the admin key. Are there any cleaner options other than executing a conjurctl command within the conjur container and munging the API Key from stdout? e.g. /bin/sh -c "docker-compose exec conjur conjurctl account create test-account-01 | sed -n -e 's/^API key for admin: //p'"?

Thank you all in advance,
Christian

Hi @Christian!

You might be using Conjur a bit non-traditionally. Accounts and their admin users usually exist long-term, storing secrets and establishing user & machine identities. Given that you’re creating & destroying new accounts for each test case, it seems like the secrets and identities associated with those accounts are more or less insignificant.

That said, there is no cleaner option for getting an admin user’s API key, though using the policy load API to create a new role should include the new role’s API key in the response JSON. I might need some more detail about how Conjur is serving your test suite to make a substantial suggestion.

  • What secrets are Conjur providing to your test suite?
  • Can these secrets be represented in an existing Conjur account?
  • Can you create & destroy a single account for the entire suite, minimizing the awkward experience?

Either way, I think what you’re trying to achieve here can be done by rethinking your policy structure. I remember this blog post being really helpful for understanding policy best-practice.

Thanks,
@john.odon

Hi John. Thank you for getting back!

This is definitely a non-traditional use case :slight_smile:, so I appreciate your flexibility!

Since I posed the question I’ve done a little more learning about the product and believe I’ve came to a more idiomatic way of using Conjur. Just as you’ve suggested, it is set up such that we create a single account for the entire unit test suite.

A little primer on our testing strategy. We’re interested in incorporating Conjur into both our unit tests and our automated staging tests.

  • Unit tests: These run in our CI pipeline each commit, and are written to run against embedded databases (etcd, hashicorp vault) with one exception for a postgres docker container.
  • Staging tests: a suite of tests that we run against ephemeral environments on a per-release basis. The creation of these ephemeral environments are fully automated with ansible + terraform. We aim to make this environment as realistic as possible. Example, in order to validate a comparable integration we have with Hashicorp Vault, we automate the creation of a new vault cluster here.

To date, we’ve got unit tests targeting a Conjur docker compose stack. The process of starting up a docker compose stack, creating an account and supplying that to our unit testing suite (via a handful of environment variables for URL, account, login and api key) is an optional/manual process. I’d love to piece together a way for this to be ran in our CI (they is currently skipped.) Any ideas here? I suspect I could go through and configure things manually once, then commit/publish conjur and postgres images for our CI to use with hardcoded creds. Although, I would prefer an option that removes myself from the upgrade path.

We also plan to include some test coverage in our staging tests. We’ve got a ton of flexibility on this one. Creating an account, loading policy, secrets, generating host identities can all happen in the most idiomatic spot, either in ansible and/or terraform upon spinning up the ephemeral staging environment, or scripted in our (serverspec/ruby) test suite. Alternatively, we have precedent (and secrets management infrastructure) for using external products in this test suite. We’d gladly accept an enterprise account if there is a free version :wink:. It may provide even better quality assurance for our customers who are using your enterprise product.

edit: realized I missed some of your questions. Hope this clears up any confusion.

What secrets are Conjur providing to your test suite?: None. We do not want to use Conjur to provide our test suite with secrets, we want to validate that our product works well with Conjur. For example our unit test suite currently creates (then deletes) templated policies ${testcase}-${randomuuid} with arbitrary foo = bar type placeholder variables in order to validate code paths in our software that interact with the API.

Thank you again,
Christian