We try to deploy a simple secret information key value pair storage service through vault, and then we realize that the data is transmitted in plaintext when it is transmitted to vault. Our security team requires that all sensitive information should be encrypted before transmission. It is not feasible to obtain plaintext during transmission.
We have considered the asymmetric encryption of confidential information and then send it to the vault backend, but this leads to the fact that vault plays little role in this process. I’m trying to find out whether vault has its own transmission encryption component and provide local encryption and decryption methods.
I know vault should ensure that the transmission process is credible in the security model. I want to know if there is a corresponding method.
Yes, the existence of HTTPS can indeed increase a certain degree of security.
However, after accessing load balancing as a service, the agent can directly obtain the corresponding information, and the security team can directly view this kind of plaintext information.
The Vault agent does not appear to be suitable for this purpose.
The HTTP request directly obtains the data, and the client goes to the vault backend.
So vault doesn’t come with a corresponding service for local encryption? If possible, would it be better to provide corresponding application services?
The load balancer should ideally be configured to pass through the encrypted connection directly to Vault, so that there is no decryption on the load balancer. The Vault Agent is used to enable integration with Vault for an application without needing to make changes to that application (for example if it is a third party application that can’t be modified).
The agent should run directly next to the application to allow secure passing of information (e.g. via properly secured files or pass through web requests). If that isn’t acceptable you can do away with the agent totally and instead talk to Vault from within the application (using one of the existing APIs). All plaintext information would then only be held within the memory space of the application, as all communication would be encrypted in transit end-to-end between the app and Vault.
This is a misconfiguration of your load balancer. You should be passing through the connection, not terminating it.
I feel like people use “security said” as a generic, “I think” and think that makes it a valid point.
The very basic idea of https says, “HTTPS protocol prevents MITM attacks” With proper SSL certificate security there is no such thing as MITM attack. HTTPS prevents such things unless you setup an insecure connection in the first place.
Vault itself assumes that if the client obtains the user key safely, this transmission is secure. (I don’t know if this is correct.)
I just looked at this issue from the perspective that there must be risks in the transmission process. If so understood, then in any case, data leakage will occur only if there is clear text in the data. (in this way, the security problem may never be solved. I know that Vault solves the problem of storage back-end, not transmission.)
What we can do is try our best to avoid that the attacker can easily get the data during transmission. In fact, it is the so-called end-to-end encryption, but it seems that I didn’t find the relevant documents in the vault. For example, in the front-end design of 1Password, all data is encrypted in the process of network transmission and will not be directly displayed in plaintext (although we can decrypt the transmitted data, at least it will not be exposed).
Is there a document describing vault end-to-end encryption?
There should be no plaintext transmission of data by Vault at any point unless things are misconfigured. HTTPS is used to ensure this is the case for transmission, as this is the generally accepted mechanism to tackle this “solved” problem for securing web requests. Vault doesn’t need to do anything additional as it would likely make things more complex for no real benefit (or likely make things less secure).
General HTTPS security measures should be used to ensure there are no problems. You should only terminate the HTTPS on Vault and not in any intermediate systems (such as load balancers) so the encrpytion is complete end-to-end. You should ensure certificates are properly handled (generated securely, stored with the right file permissions, not leaked & checked by the client). Depending on your setup this could be done via an internal only CA or publicly valid certificates - either way you need to ensure that the client is correctly validating the certificate to prevent any form of man-in-the-middle attack.
" There is no mutual trust between the Vault client and server. Clients use TLS to verify the identity of the server and to establish a secure communication channel. Servers require that a client provides a client token for every request which is used to identify the client. A client that does not provide their token is only permitted to make login requests."
