How does sidecar deployment work in the context of Vault?

Implementing a sidecar in the context of Vault is a pattern where a separate container (sidecar) is deployed alongside the main application container within a single pod (for example, in Kubernetes). This sidecar container is responsible for interacting with Vault, performing authentication operations, and retrieving secrets on behalf of the main application.

Key aspects of operation:

1. Deployment: The sidecar container is added to the pod definition alongside the application container.
2. Initialization: The sidecar container usually starts before or simultaneously with the main application. It performs Vault-related tasks first.
3. Authentication: The sidecar uses Vault authentication methods for Kubernetes (e.g., Kubernetes Auth Method). It obtains a Vault token.
4. Retrieving secrets: The sidecar uses the obtained token to read secrets from Vault.
5. Providing secrets to the application: The sidecar can provide secrets to the application in various ways:
   • Writing files to a shared volume mounted by both containers.
   • Injecting environment variables.
   • Providing a local HTTP interface that the application can access for secrets.
6. Secret renewal: The sidecar can periodically renew secrets obtained from Vault and notify or update files/variables for the main application.
7. Isolation: The main application does not need direct communication with Vault and does not contain authentication/secret retrieval logic. All this responsibility lies with the sidecar.
8. Minimal privileges: The main application can operate with minimal privileges since interaction with Vault is delegated to the sidecar.

Example of usage with Kubernetes and Vault Agent Injector:

Vault Agent Injector is a Kubernetes controller that automatically modifies pod definitions upon creation, adding a Vault Agent sidecar container.

1. The application has annotations in the Deployment manifest:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-app
   spec:
     ...
     template:
       metadata:
         annotations:
           vault.hashicorp.com/agent-inject: "true"
           vault.hashicorp.com/role: "my-app-role"
           vault.hashicorp.com/agent-inject-template-secrets: |
             {{- with secret "secret/data/myapp/config" -}}
             DB_USER={{ .Data.data.db_user }}
             DB_PASSWORD={{ .Data.data.db_password }}
             {{- end -}}
   # ... rest of the manifest
   

2. The Vault Agent Injector intercepts the creation of the pod and adds the vault-agent sidecar container and the vault-agent-init init container.

3. The vault-agent-init (for obtaining secrets before the main container starts) or vault-agent (for dynamic secrets and renewal) performs:

   • Authentication to Vault using the Kubernetes pod token and the specified role.
   • Reading the secret secret/data/myapp/config.
   • Rendering the template and writing environment variables (as in this example) or a secrets file to a shared volume /vault/secrets.

4. The main application container mounts this volume and reads secrets from the file or receives them from environment variables.

Advantages:

• Centralization of Vault interaction logic in the sidecar.
• Reduced complexity of the application code.
• Automatic renewal of tokens and secrets.
• Security risk isolation.