search

mittwald / kubernetes-secret-generator

Kubernetes controller for automatically generating and updating secrets
Apache License 2.0
330 stars 57 forks source link

Allow annotations to be added per generated value #36

Closed day1118 closed 3 years ago

day1118 commented 3 years ago

Is your feature request related to a problem? Please describe. I would like to generate a single secret with two generated values (which is supported), but I would like them to have different lengths. Specifically, I also need to use the hex encoding also. The values are intrinsically related, so I would like them to share a single secret.

Describe the solution you'd like Allow the annotations to include the generated field name:

apiVersion: v1
kind: Secret
metadata:
  name: credentials
  annotations:
    secret-generator.v1.mittwald.de/autogenerate: id,password
    secret-generator.v1.mittwald.de/length/id: '8b'
    secret-generator.v1.mittwald.de/encoding/id: 'hex'
    secret-generator.v1.mittwald.de/length/password: '16b'
    secret-generator.v1.mittwald.de/encoding/password: 'hex'

For backwards compatibility, secret-generator.v1.mittwald.de/encoding and secret-generator.v1.mittwald.de/length would be maintained as the default, and providing an annotation with the key in the path would override for only that key.

Describe alternatives you've considered Using two secrets, one for each value does work, but results in more secrets and does not make it as clear the values are related.

Additional context This could potentially be handled as part of https://github.com/mittwald/kubernetes-secret-generator/issues/34

day1118 commented 3 years ago

After looking further at examples of annotations from cloud.google.com, I think this could be done as:

apiVersion: v1
kind: Secret
metadata:
  name: credentials
  annotations:
    secret-generator.v1.mittwald.de/autogenerate: 'id,password'
    secret-generator.v1.mittwald.de/length: '{"id": "8b", "password": "16b"}'
    secret-generator.v1.mittwald.de/encoding: 'hex'   # Optionally could be a map also

This would work by checking if the annotation is of type map and process each key. If it is only a string, it can be assumed that the provided value applies for all generated keys. This would ensure full backward compatibility.

YannikBramkamp commented 3 years ago

Hello, thank you for you suggestion. After giving it some thought, we decided that I will integrate this into the CRD implementation from #34, while leaving the annotation-based approach as is, as the CRDs allow for a more elegant way of implementing this. I will try to get to work on this shortly, however, I cannot make a promise as to when it will be finished.

mittwald-machine commented 3 years ago

There has not been any activity to this issue in the last 30 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.

mittwald-machine commented 3 years ago

There has not been any activity to this issue in the last 30 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.

mittwald-machine commented 3 years ago

There has not been any activity to this issue in the last 30 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.

mittwald-machine commented 3 years ago

There has not been any activity to this issue in the last 30 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.

mittwald-machine commented 3 years ago

There has not been any activity to this issue in the last 30 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.