---
title: Charmhub | Deploy Content-cache using Charmhub - The Open Operator Collection
description: Deploy the latest version of Content-cache as a Kubernetes Operator on
  any cloud.
url: https://charmhub.io/content-cache-k8s/docs/explanation-security
---

# Content-cache

[Canonical IS DevOps](https://charmhub.io/publisher/canonical-is-devops "View all packages from Canonical IS DevOps")

* [Canonical IS DevOps](https://charmhub.io/publisher/canonical-is-devops "View all packages from Canonical IS DevOps")

Platform:

stable 49

```
juju deploy content-cache-k8s
```

[Learn to deploy on juju >](https://juju.is/docs/juju/manage-applications)

---

#### Relevant links

* [Homepage](https://github.com/canonical/content-cache-k8s-operator)

---

#### Contacts

##### Maintainers

+ [Launchpad Team](https://launchpad.net/~content-cache-charmers)

* [Submit a bug](https://github.com/canonical/content-cache-k8s-operator/issues)

---

Share your thoughts on this charm with the community on discourse.

[Join the discussion](https://discourse.charmhub.io/)

# Security

This document describes the security design of the Content Cache K8s charm. The charm manages a [nginx web server](https://nginx.org/) configured as a static web content cache. This document will detail the risks and good practices.

## [Machine-in-the-middle attack](https://charmhub.io/content-cache-k8s/docs/explanation-security#p-39091-machine-in-the-middle-attack)

This type of attack refers to an attacker intercepting messages and pretend to be the intended recipient of the message.
For example, if an user tries to access `ubuntu.com`, an attacker might intercept the packets and pretend to be `ubuntu.com`, and trick the user to reveal their password.
The way to prevent this would be using TLS certificates to valid the identity of recipient.

The incoming traffic to the charm should be encrypted with SSL to ensure that attackers cannot impersonate domains cached by the charm.

### [Good practices](https://charmhub.io/content-cache-k8s/docs/explanation-security#p-39091-good-practices)

Enable TLS certificates with the [`tls_secret_name` configuration](https://charmhub.io/content-cache-k8s/configurations#tls_secret_name).

## [Caching of sensitive data](https://charmhub.io/content-cache-k8s/docs/explanation-security#p-39091-caching-of-sensitive-data)

The Content Cache K8s charm caches the response of the host and reuse it for future requests.
If the response from the host contains sensitive data, then the response should not be stored and reused for future requests.

For example, a response with `Set-Cookie` header is commonly used to store a login session to the client browser. If this response is cached and reused for future requests then other people might gain access to the login session of the original request.

When Nginx designed the content cache feature, this risk was considered. By default Nginx does not cache responses with `Set-Cookie` in the header.
The host can also control the caching behaviors with `Cache-Control`.
By default, Nginx respects the `Cache-Control` header. If the header is set to a value such as `private`, `no-cache`, or `no-store`, Nginx would not cache the response.
The charm does not override this default setting.

### [Good practice](https://charmhub.io/content-cache-k8s/docs/explanation-security#p-39091-good-practice)

Check if the hosts being cached are using the `Cache-Control` to prevent caching for sensitive responses.

---