Skip to content
This repository has been archived by the owner on Oct 19, 2024. It is now read-only.

Handling of secret #107

Closed
yuzujoe opened this issue Jul 4, 2020 · 5 comments
Closed

Handling of secret #107

yuzujoe opened this issue Jul 4, 2020 · 5 comments
Milestone

Comments

@yuzujoe
Copy link

yuzujoe commented Jul 4, 2020

Why are we dealing with secrets in the form of notifiers.yaml?

I find it very difficult to use as it makes it incompatible with other secrets.
Also, because of using stringData, the only way to save values is to store them in plain text, which is a risk from a security perspective.

If there is a way to handle resources such as ExternalSecrets and SaledSecrets flexibly, I would like to see some documentation.

@booleanbetrayal
Copy link

This can be done pretty easily with the Helm deployment for argocd-notifications. There's a value (.secret.create) that can be toggled to false. At that point, just ensure your ExternalSecret is named identical to the expected Secret (argocd-notifications-secret) and that it provides the correct key:

apiVersion: kubernetes-client.io/v1
kind: ExternalSecret
metadata:
  labels:
    app.kubernetes.io/instance: argocd
    app.kubernetes.io/name: argocd
    argocd.argoproj.io/instance: argocd
  name: argocd-notifications-secret
  namespace: argocd
spec:
  backendType: secretsManager
  data:
  - key: your-externally-backed-encrypted-store-notifiers-yaml
    name: notifiers.yaml
  template:
    metadata:
      annotations:
        app.kubernetes.io/part-of: argocd
        managed-by: argocd.argoproj.io

@diranged
Copy link

I'd like to second that this is a difficult thing to work around. We're working on a similar problem. We should be able to set these types of secrets with environment variables, so that we can pass them into the Pod definition through any mechanism that we choose. This should frankly simplify the notifications code entirely, and be more flexible.

@alexmt
Copy link
Collaborator

alexmt commented Dec 30, 2020

I've borrowed the better secret handling from Argo CD and implemented it in release-1.0.

In the next version all settings are managed in config map and secret values from argocd-notification-secret can be referenced as $secret-key. Example:

What do you think?

@alexmt
Copy link
Collaborator

alexmt commented Jan 20, 2021

I believe secret handling is improved now. At least it is now the same as secret handling in Argo CD, so closing it.

Please let me know if I'm missing something and issue should be reopened.

@alexmt alexmt closed this as completed Jan 20, 2021
@musabmasood
Copy link

musabmasood commented Nov 9, 2021

How do you get those secrets into the templates? I created an issue for this:

#357

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants