Hey @jburns -
In the policy sample you gave, are the deployment
names for Secretless and the authenticator container address/secretless
and address/authenticator
, respectively? The form of the deployment
-based application identity is usually something like conjur/authn-k8s/{authenticator/service ID}/apps/{namespace}/deployment/{deployment_name}
(based on the application identity docs here). I would expect the Secretless and authenticator containers to be defined in the same deployment as the application - without seeing your manifest, it’s hard to tell if this is the case or not.
If you are using the authenticator client and Secretless together, I would suggest mounting the Conjur access token retrieved by the authenticator into the Secretless container in the same way that you mount the access token into the application container (there are some example manifests that do this in the docs here).
Once you mount the access token into the Secretless container, you can configure it to communicate with DAP using the access token the same as you would configure your application - by specifying:
-
CONJUR_AUTHN_TOKEN_FILE
- eg/run/conjur/access-token
-
CONJUR_APPLIANCE_URL
- eghttps://conjur-follower.<CONJUR_NAMESPACE_NAME>.svc.cluster.local/api
CONJUR_ACCOUNT
CONJUR_SSL_CERTIFICATE
in the Secretless container environment.
This does mean that you have to give Secretless and the authenticator the same secret access in DAP, but you do get the added benefit of not having to worry about your app logging the secrets to connect to the resources that Secretless is managing.
We are hoping to add many new connectors for Secretless this year - which ones are we missing to enable you to go full-Secretless in this workflow?
If you are interested, we also released a new SDK for contributing Secretless connectors. In addition, we have an open issue for enabling container-based identity here - if this workflow is appealing to you and is something you would use, I encourage you to leave your feedback on that issue.
I look forward to hearing more from you - but if following this post we find there are still questions about your deployment configuration, it might be a good time to open up a Salesforce case to dig a little deeper into your specific problem.
Thanks, and I hope this is helpful -
Geri