I’m curious to know what customers strategies are for managing and protecting the API keys used to access secrets protected by DAP/Conjur.
When developers ask what the value of exchanging a clear text password for a clear text API key we can certainly offer the explanation that when integrated with EPV we are able to perform rotations but I’ve seen this not be truly satisfying to some people. If one compromised the key then they would be able to expose all passwords.
Do you combine this with AIM? Do you use encryption on scripts? Any assistance would be appreciated
If the API key is a key for a developer user of the system, then they should store the key in their own local keystore (which might be their OSX keyring or software like LastPass).
If you’re speaking instead about application identities, depending on the system the application is deployed to we have a variety of integrations available. With these integrations we’re aiming to solve the secret zero problem by using native system attributes to verify the app identity and get it access to the secrets it needs.
It’s worth also noting, regarding your comment
If one compromised the key then they would be able to expose all passwords.
it’s always best practice to only entitle your applications / users to access the secrets that they need, and nothing more. That is, you should be applying the principle of least privilege to your application entitlements to ensure that even in the event of a breach, the attacker would not have access to all passwords.
Hope that helps to clarify this - and if you have any questions about specific integrations, please let us know. Thanks!
I’m totally on board with the least privilege approach! This definitely limits the blast radius and is something we always strive to enforce.
That being said I’m sure you can understand the conversations that occur when developers get wise to the fact that they are exchanging one hard coded secret in their code/script for another hard coded secret.
Secretless is a really cool concept and I’d love to see how things develop. It would be great if future releases of DAP/Conjur was able to do auth like AIM/AAM does (ip, hash, os user etc). I think there is a lot of value to be had by combining both technologies.
To expand on what @izgerij mentioned, there is an option to CIDR restrict hosts. It’s not currently documented, but you can add CIDR restrictions to hosts as outlined below. Note: You will need to do SSL offloading on the load balancer so that the X-Forwarded-For header is properly added to the traffic. Otherwise, all connections will appear to be coming from the load balancer and CIDR restrictions won’t work as expected.
To CIDR restrict a host:
- !host id: my_host restricted_to: <ip address or range>
The IP address can be in CIDR notation, and/or comma separated list, and/or a combination of the two. Lists need to be wrapped in square brackets .
172.17.0.2 (this is automatically translated to 172.17.0.2/32, so either format works in that case)
192/168.0.0/24 (/24 range, probably not a good idea to go that broad )
[172.17.0.2,172.17.0.3/32] (list of individual /32 IP addresses, again, either format is accepted)
[192.168.0.0/24,172.17.0.2] (list consisting of a /24 range and a /32 address
Side note: CIDR restrictions work with both host factory token redemption and host creation via host factory as well. E.g., you can redeem a CIDR restricted HF token to create a CIDR restricted host. Let me know in a separate thread if there is any interest in that.
One new discovery another customer has made is that the UI doesn’t evaluate the client IP address correctly, so once you turn on CIDR restrictions the host can’t login via the UI because all of the source IP information is lost and the logs show the source as 127.0.0.1. So you can effectively render the UI to only be usable by the built in admin user by defining CIDR restrictions on all of your hosts. Might be a consideration as a mitigation technique for the security bulletin we just released about an XSS risk with the UI, since that vulnerability depends on an authenticated user. Combine that with a 20+ char password for the admin user and you can buy some time until you’re ready to upgrade to 11.3.
)