Change:
This issue was reported in the Description When configuring components of infrastructure, environment variables allow a trivial method of gathering settings. However, not all settings should be derived from these variables. For example, the file used the CFSSLCAPKPASSWORD environment variable, where a plain-text password should be found within the variable. Figure 8.1: A string password being recovered from the CFSSLCAPKPASSWORD environment variable. If this variable is configured, an attacker could potentially gain access to its stored value through environment logging, or further exploitation of the endpoint. The assessment team found seemingly sensitive environment variables in at least the following locations: Exploit Scenario Alice configures her environment with the CFSSLCAPKPASSWORD environment variable. Eve gains access to Alice’s environment and determines that the CFSSLCAPK_PASSWORD environment variable is set. Because this variable contains the private key password, Eve is able to recover the private key and use it trivially, leading to further exploitation of Alice’s environment. Recommendation Short term, ensure highly sensitive information is not collected directly from environment variables for long periods of time. Long term, consider using Kubernetes secrets for all areas of the system. This will allow users to have one unified interface and location for all secrets, and avoid accidentally exposing secrets to other users within a host system. Anything else we need to know?: See for current status of all issues created from these findings. The vendor gave this issue an ID of TOB-K8S-005 and it was finding 9 of the report. The vendor considers this issue Medium Severity. To view the original finding, begin on page 35 of the Environment: Kubernetes version: 1.13.4
/sig auth /sig cloud-provider /area security /kind bug /remove-kind feature
Also secrets
Bug triage for 1.17 here with a gentle reminder that code freeze for this release is on November 14. Is this issue still intended for 1.17?
is it ok to close this issue also cc:
no, still remains
cc
seen this yet?
Thanks for the attention, we are using it as a fallback option mostly for test and dev env, we are working to remove them.
AFAIK is the only use for this testing. Would it be appropriate to move this code into ?
Submitted a PR to move password retrieval to

Discussion:
func configFromEnv() (cfg Config, ok bool) { cfg.Global.AuthURL = os.Getenv("OS_AUTH_URL") cfg.Global.Username = os.Getenv("OS_USERNAME") <del> cfg.Global.Password = os.Getenv("OS_PASSWORD") </del> cfg.Global.Region = os.Getenv("OS_REGION_NAME") cfg.Global.UserID = os.Getenv("OS_USER_ID") cfg.Global.TrustID = os.Getenv("OS_TRUST_ID")

[Metadata] search-order = configDrive, metadataService `)) <ins> cfg.Global.Password = os.Getenv("OS_PASSWORD") </ins> if err != nil { t.Fatalf("Should succeed when a valid config is provided: %s", err) }

} } <ins> func configFromEnvWithPasswd() (cfg Config, ok bool) { cfg, ok = configFromEnv() if !ok { return cfg, ok } cfg.Global.Password = os.Getenv("OS_PASSWORD") return cfg, ok } </ins> func TestNewOpenStack(t *testing.T) { <del> cfg, ok := configFromEnv() </del> <ins> cfg, ok := configFromEnvWithPasswd() </ins> if !ok { t.Skip("No config found in environment") }

} func TestLoadBalancer(t *testing.T) { <del> cfg, ok := configFromEnv() </del> <ins> cfg, ok := configFromEnvWithPasswd() </ins> if !ok { t.Skip("No config found in environment") }

var diskPathRegexp = regexp.MustCompile("/dev/disk/(?:by-id|by-path)/") func TestVolumes(t *testing.T) { <del> cfg, ok := configFromEnv() </del> <ins> cfg, ok := configFromEnvWithPasswd() </ins> if !ok { t.Skip("No config found in environment") }