-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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.
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
Draft for a new feature to support Secrets as a type of parameters #11446
Conversation
Signed-off-by: Jinsu Park <dev.umijs@gmail.com>
Signed-off-by: Jinsu Park <dev.umijs@gmail.com>
@terrytangyuan Could you please take a look at the current approach? |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is a mentoring request, please provide an update here. Thank you for your contributions. |
Looks like this slipped through my inbox. Would you like to go through your proposal during the contributors' meeting? It's totally ok if not but you'll get feedback faster from others. |
@terrytangyuan Thanks for the comment! Unfortunately, I'm quite busy these days, so I don't think I have time to attend the contirubtor meeting. For now, I feel like focusing more on other simpler issues. |
This issue has been closed due to inactivity. Feel free to re-open if you still encounter this issue. |
secret, ok := obj.(*apiv1.Secret) | ||
|
||
if !ok { | ||
return "", fmt.Errorf("unable to convert object %s to configmap when syncing Secrets", name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should probably mention secret
and not configmap
is there any chance this PR can be revived? i think |
Feel free to pick it up. |
Related to #5506
Disclaimer
This is just a draft, and the purpose of this PR is to look for a mentor who could help me with detailed implementations. As the test code has not been modified, the tests will fail, and this PR lacks test code at moment.
Motivation
Currently, we can use parameters referring to ConfigMaps but cannot use parameters referring to Secrets.
Modifications
I added a new type of parameters that refer to Secrets based on the code for the case where a parameter refers to ConfigMaps.
Verification
THIS_IS_SAMPLE_CREDENTIAL
.Concerns
1. Credentials are not redacted properly.
For the current implementation, the plain value of secrets are shown in logs and Pod manifests as follows:
I have a concern about the current implementation not properly masking the actual value of credentials. However, making significant changes to how we pass arguments and log them would be required to fully redact these credentials.
Therefore, my suggestion is to introduce this implementation initially. If it's found insufficient in terms of redacting credentials, we can consider modifying the fundamental implementation of passing arguments. Ultimately, this will enable us to achieve proper redaction of credentials.
2. The interfaces of APIs and definitions of CRD will be updated.
Since I added a field
secretKeyRef
to parameters, the interfaces of APIs and definitions of CRD will be updated. I'd like to confirm if this is allowed and whether the CRD version should be increased.From my research on a previous case involving the introduction of
configMapKeyRef
1, I noticed that while the API and CRD were modified, the CRD version didn't increase.Footnotes
https://github.com/argoproj/argo-workflows/pull/6662 ↩