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.

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

Support for Retrieving Multiple JSONPath Keys Simultaneously in kubectl Commands #1693

Open
D0ri123 opened this issue Jan 1, 2025 · 1 comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@D0ri123
Copy link

D0ri123 commented Jan 1, 2025

What would you like to be added:
Currently, when using kubectl get secret with jsonpath, we can extract the value of a single key, as shown in the following example:

kubectl get secret -n {namespace} {example-config} -o jsonpath='{.data.A}' | base64 --decode

Here, the jsonpath argument specifies the path to a single environment key (A), and the corresponding value can be retrieved. However, if multiple keys need to be retrieved simultaneously (e.g., A and B), it requires multiple commands or a complex workaround.

Feature Request:
Extend the jsonpath functionality to allow specifying multiple keys in a single command, making it possible to retrieve multiple values at once. For instance:

kubectl get secret -n {namespace} {example-config} -o jsonpath='{.data.A, .data.B}' | base64 --decode

If possible, I would like to contribute by adding this feature myself.

Why is this needed:
By simplifying the process of retrieving a single secret, the workload is reduced, and secret values can be fetched more efficiently.

@D0ri123 D0ri123 added the kind/feature Categorizes issue or PR as related to a new feature. label Jan 1, 2025
@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Jan 1, 2025
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
None yet
Development

No branches or pull requests

2 participants