Hello Team - I understand that any apps/hosts that requires access to secrets stored in Conjur need to authenticate to the Conjur as a first hop. Can someone clarify the below questions ?
Does this mean the summon tool needs to be installed on all the hosts/apps that needs to authenticate to Conjur ? (excluding hostfactory for now)
If Summon needs to be installed - then the only way it does authenticate to Conjur is by using .netrc or conjur.identity correct ?
How are we delineating the risk of storing the /etc/conjur.identity file which basically stores the credentials in clear text ?
Can we use a rest authentication API using /etc/conjur.identity file ?
If CONJUR_AUTHN_LOGIN and CONJUR_AUTHN_API_KEY or CONJUR_AUTHN_TOKEN or CONJUR_AUTHN_TOKEN_FILE or CONJUR_AUTHN_JWT_SERVICE_ID are not provided, the username and API key are read from ~/.netrc , stored there by conjur authn login .
This means that when invoking Summon you can pass in the CONJUR_AUTHN_LOGIN and CONJUR_AUTHN_API_KEY environment variables, or an access token via CONJUR_AUTHN_TOKEN, or a path to an access token via CONJUR_AUTHN_TOKEN_FILE.
The NETRC file is not required if one of the above paths are taken.
No. You can authenticate through the API using our SDKs or by using some of our integrations. Summon is just an easy way of providing secrets to a process that needs to be executed when no integration exists and an API call is not feasible.
Since Summon is not a requirement, this is not necessary at all. It is a requirement, however, for Summon to be able to know where Conjur’s service exists and how to authenticate to the service.
The /etc/conjur.identity file, or in some cases it can be a .conjurrc file, is a file that should be treated similar to a .netrc file. Therefore, only root should have access to read the file. Using basic file permissions, you can control the access to the file. This is a risk assessment you should evaluate on your own in deciding whether to use Summon or one of the SDKs/Integrations I linked above instead.
Our SDKs can accept the file as a means of authentication, but as you noted in #3, this isn’t the most secure solution. I would recommend running your service in a containerized platform, such as Kubernetes, and utilizing our Kubernetes Authenticator explained in the “Integrations” link above to have an attribute-based authentication to Conjur and eliminate the need to store an API key altogether. Alternatively, check out our Secretless Broker at https://secretless.io to understand how you can completely remove ALL secrets from your applications and adhere to the 12-Factor App guidelines set forth at https://12factor.net.