Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: add design for adding new arguments for TLS #173

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

docs: add design for adding new arguments for TLS #173

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ab3dfbf
docs: add design for using services for addons pods
bipuladh Nov 15, 2024
54f3cab
Addressing more comments; Makes changes to the proposal
bipuladh Dec 5, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions docs/design/podService.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
# Add support for TLS certificates for CSI Addons communication

The Kubernetes CSI Addons project currently connects the CSI Addons Manager to the add-on sidecar without TLS in place.
We propose a introduction of an arugment which enabled should mount the TLS certificates into the sidecar container.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please provide a code snippet that describes the desired outcome of this new field within the API you would like to augment.

The code snippet should be descriptive enough so the following will be clear:

  1. The name of the new field
  2. The type of the new field
  3. The API is being introduced into
  4. The location (path) in the API where the new field will be added
  5. An explanation of what the field is describing
  6. And validation rules needed on the field (can be provided as standalone text or as a comment within the snippet)

The operator is only responsible for propagation of the certificates.

## Problem Statement

CSI addons sidecar which is being deployed here needs certificates. Currently we have no argument to enable this propagation of certificates.

## Proposed Solution

### Introduce a new argument for TLS

We introduce a new argument in the commands to enable TLS. It is diabled by default. But if this is enabled the deployer is expected to have mounted a secret that contains the required certificates. We will essentially need a certifiate that is compatible with the hostname that the manager will be issuing network calls using it.


### Operator changes

The Ceph CSI Operator is only responsible for taking in the information mounted to it and project those as volumes in the CSI Addons sidecar. The deployer of CSI Addons should create these certificates and mount it at `/etc/tls/tls.crt` and `/etc/tls/tls.key`. We keep this hardcoded to reduce the number of new arguments introduced. The logger should provide enough information if the user is not mounting this correctly for easy debugging.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bipuladh I am not sure I understand

The deployer of CSI Addons should create these certificates

Can you please elaborate or rephrase?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not possible. I have updated the doc to reflect that client operator would pass the certificate using a secret. The locator for the secret will be added in a new field that I propose in the latest commit.


## Guide to the deployeer for handling certificates

Since we use host networking the certificates should have these IP addresses as valid Subject names.