add get secrets command #193
Conversation
Signed-off-by: Manabu McCloskey <[email protected]>
|
I like the idea of using the labels to allow the adhoc credential printing, but will this search all namespaces? If not how do we know in advance which namespaces to query? |
|
This is a great idea that you propose here. 2 remarks
|
|
Thanks for this, I like the idea. big +1 from me on what @cmoulliard suggested. As for the command, to stay closer to the kubectl syntax, I would call it The latter is particularly useful for demo purposes with codespaces or c9. Also the |
The idp tool should translate that. Command proposed then is: Example: Remark: If we provision in the future different clusters, then we could extend the command with an additional parameter: |
|
Great idea! also +1 to Charles' comments. |
Signed-off-by: Manabu McCloskey <[email protected]>
Signed-off-by: Manabu McCloskey <[email protected]>
|
Changed commands to Per Charles' comment, I've introduced two labels keys:
I've also introduced a flag called When you run ./idpbuilder get secrets
---------------------------
Name: gitea-admin-secret
Namespace: gitea
Data:
password : giteaPassword
username : giteaAdmin
---------------------------
Name: argocd-initial-admin-secret
Namespace: argocd
Data:
password : abc./idpbuilder get secrets -p argocd
---------------------------
Name: argocd-initial-admin-secret
Namespace: argocd
Data:
password : abc |
There was a problem hiding this comment.
some minor changes otherwise looks good.
On a separate note, since we now support selection by package name, I wonder whether there should be another command that lists the packages installed. Also, we should probably pull this k8s specific logic out into a pkg repo where they can be added to idpBuilder and later on possibly to the cnoe CLI when we need to enable similar functionality for a remote cluster.
Let me know what you all think and we can create separate issues to refactor things and add the list command. This PR can go in for now IMO.
pkg/cmd/get/secrets.go
Outdated
| } | ||
| } | ||
|
|
||
| return renderTemplate("templates/secrets.tmpl", outWriter, secretsToPrint) |
There was a problem hiding this comment.
| return renderTemplate("templates/secrets.tmpl", outWriter, secretsToPrint) | |
| return renderTemplate(secretTemplatePath, outWriter, secretsToPrint) |
| req, pErr := labels.NewRequirement(v1alpha1.PackageNameLabelKey, selection.Equals, []string{p}) | ||
| if pErr != nil { | ||
| return fmt.Errorf("building requirement for %s: %w", p, pErr) | ||
| } | ||
|
|
||
| pkgSelector := selector.Add(*req) | ||
|
|
There was a problem hiding this comment.
Not sure why this bit needs to sit outside getSecretsByCNOELabel. I'd say implement this all in that same function.
Signed-off-by: Manabu McCloskey <[email protected]>
Related to #150
When you create a new cluster, the first thing you typically do is go to the ArgoCD UI to check on status. We currently tell users to run the kubectl command to get the admin secrets rather than us providing the information directly. This works as long as that's all the information you need from the cluster.
When you start involving more complex things, it gets messier. For example, when you use the reference implementation example, you have to run a few different kubectl commands to get all credentials required to fully interact with the things deployed in the cluster. I find this quite annoying to document and run as an end user.
I want to allow users to get all information with one command and would like to introduce the
export secretcommand. This command does two things:cnoe.io/exportable=true.By default it looks like this:
If using the ref impl example, then you just have to label the secrets that you want end users to see.