Proposal: Add a --config-file parameter for easier switching between StackRox instances?

[kastl-ars]

I just get started using StackRox and roxctl, so please excuse, if those are newbie questions that were asked and answered before.

From what I found in the docs and the roxctl help, I can set most things I need for roxctl in environment variables.

Setting a token as an environment variable that every process in my shell can read sounds like something that could be problematic. Setting the ROX_API_TOKEN_FILE variable pointing to a file is better.

But still, this means I need to set three different variables (token file, endpoint, CA file) each time I "switch between StackRox instances". Not sure how often I need to actually do something with roxctl.

Using different customer's clusters, it would be nice if roxctl supported a --config-file argument or a configuration file with multiple contexts, like kubeconfig.

The latter might be hard to implement, but a --config-file argument might be easy hanging fruit?

Have a nice weekend!

Kind Regards, Johannes

[stehessel]

Hi @kastl-ars, I think this is a great idea. I created a ticket in our internal tracker for this. I would also leave this issue open in case somebody is interested in an external contribution.

[randyttruong]

Hi, is this ticket still open? I'd love to take a crack at it.

[stehessel]

Hi @randyttruong, yes this issue is still open and nobody else is working on that right now as far as I know. If you have ideas about the implementation (like config files vs contexts a la kubectl already mentioned above), feel free to drop them here and I'll ask the team for feedback.

[randyttruong]

Hi @stehessel, here's an idea for the config file implementation where I added to the flags package, while keeping everything decoupled:

1) Add a new flag to the roxctl command tree called --config-file, whose methods will be located in roxctl/common/flags/config-file.go

2) Create new package variables for flags:

• flags.configFile- Filename for the configuration file
• flags.configApiTokenFile - Filename for API Token File
• flags.configApiTokenFileSet- Boolean flag that is set if an API Token File is added
• flags.configCaCertificateFile - Filename for CA Certificate
• flags.configCaCertificateFileSet - Boolean flag that is set if a CA Cert is added
• flags.configEndpoint - Name for endpoint
• flags.configEndpointSet - Boolean flag that is set if an endpoint is added

3) Create new package methods for flags

• flags.ConfigurationFile() - Returns filename of configuration file
• flags.ReadConfigurationFile() - Parses configuration file, setting flags as necessary
• Getter methods for all related flags

4) Edit methods located outside of flags that depend on flags.endpoint, flags.caCertFile, and flags.apiTokenFile to also account for existence of configuration file

• Perhaps the priority order should be flags > configuration file > environment variables?

Let me know what you think.

[stehessel]

Thanks for your interest and proposal @randyttruong. Here are some pointers based on our vision for roxctl.

• Our ideal target state for config and context management would be to follow the conventions laid out by kubectl. That will allow us to implement context manipulation via roxctl and present users with a known interface.
• As a result, the schema for the config file should align with that goal.
• For an MVP implementation, we don't need to implement all the bells and whistle (i.e. context manipulation commands) that kubectl provides. So to start out, a single context/Central per config file would be sufficient. But the design and schema should allow for the eventual implementation of multiple contexts.
• roxctl central machine-to-machine already store some connection information in a file in XDG_RUNTIME_DIR. We should make sure that any new config file is compatible and overlays as expected.

Let me know if you prefer to start off with a draft PR or if you'd like to discuss the design further.

[randyttruong]

Hi @stehessel, your pointers are very informative! It makes a lot of sense to keep the experiences between roxctl and kubectl as consistent as possible, so the workflows between the two applications can be seamless.

Just to clarify from your post, the primary workflow of setting a roxctl config using the --config-file flag is acceptable. When consuming a configuration file, however, we want to use an identical schema to that of kubectl. Additionally, we also need to hash out how exactly values from the configuration file will interact with values stored in XDG_RUNTIME_DIR / ROX_CONFIG_DIR.

For immediate questions, should values from the configuration file be stored as a field for RoxctlConfigs like RoxctlConfigs.CentralConfigs?

Let us start with a draft PR for now. I think that the current workflow that I proposed in my last post should be easy to implement. From there, I can work on fleshing out the design more, such as designing a new command tree branch, etc.

[stehessel]

Yes that is correct 💯. Looking forward to your contribution :)