fix: keep env values out of calcium logs; warn on options cocoon cannot apply - #758
Merged
Merged
Conversation
CreateWorkload, CalculateCapacity, RunAndWait and ExecuteWorkload attached the whole options struct as a log field, so deploy and exec env values (and file contents, base64 in JSON) reached every info and error line. The options dump now carries env keys only, and the loggers name the app or workload instead.
cocoon vm create has no way to apply env, dns, extra hosts, the entrypoint commands or its dir, and the engine dropped them without a trace. The engine now logs a warning naming them. Core's own env keys move into cluster constants so the check skips what core adds to every workload.
…build logs ReplaceWorkload, Send and BuildImage attached their whole options as a log field, so replace env, sent file contents (base64) and build envs and args reached their info and error lines. The loggers name the app, the target IDs or the image instead.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two small fixes.
Env values in logs.
CreateWorkload,CalculateCapacity,RunAndWaitandExecuteWorkloadattached the whole options struct as a log field. Deploy and exec env values reached every info and error line, and deploy file contents did too (base64 in the JSON field). The options dump now carries env keys only (DeployOptions.Redacted), and the loggers name the app or the workload ID instead.ReplaceWorkload(which embeds the deploy options, reached byreplaceanddeploy --auto-replace),Send(file contents) andBuildImage(build envs and args) had the same full-options field and now name the app, the target IDs or the image.cocoon ignores some create options without a trace.
cocoon vm createhas no flag for env, dns, extra hosts, entrypoint commands or entrypoint dir, so the engine dropped them without any log. It now logs a warning that names them. Core's ownAPP_NAME/ERU_*env keys move intoclusterconstants, so the check skips them; the process engine uses the same constant forERU_POD. Applying these options inside a guest would need cocoon support first (cidata), which is out of scope here.Verified with a throwaway probe at info level. For replace, send and build: before the change each line carried its secret; after it, none do. For create and exec: before the change, 3 log lines carried the secret env values; after it, none do, and the dump shows
Env:[]string{"DEPLOY_TOKEN"}. A cocoon create with core env only logs nothing; one with a deploy env logscocoon does not apply env to vm <name>.