Lambda Environment Variables are not actually used

[mettke]

Describe the bug
The template.yaml files contains the following environment variables:

SSOSYNC_GOOGLE_CREDENTIALS: !Ref AWSGoogleCredentialsSecret
SSOSYNC_GOOGLE_ADMIN: !Ref AWSGoogleAdminEamil
SSOSYNC_SCIM_ENDPOINT: !Ref AWSSCIMEndpointSecret
SSOSYNC_SCIM_ACCESS_TOKEN: !Ref AWSSCIMAccessTokenSecret

These variables, however, are not actually used in the source code. Instead secrets.go contains hard coded values.

Expected behavior
Environment Variables should be used to allow configuration of the ssosync app.

[christiangda]

@mattsb42-aws that is not true, the env vars are loaded here

...
func initConfig() {
	// allow to read in from environment
	viper.SetEnvPrefix("ssosync")
	viper.AutomaticEnv()

	appEnvVars := []string{
		"google_admin",
		"google_credentials",
		"scim_access_token",
		"scim_endpoint",
		"log_level",
		"log_format",
		"ignore_users",
		"ignore_groups",
		"include_groups",
		"user_match",
		"group_match",
		"sync_method",
	}

	for _, e := range appEnvVars {
		if err := viper.BindEnv(e); err != nil {
			log.Fatalf(errors.Wrap(err, "cannot bind environment variable").Error())
		}
	}

...

https://github.com/spf13/viper is who make the magic possible.

[mettke]

Yes I corrected the issue description to only reference the secret manager env variables. And for them it still seems to be true. 'Cause even though they are given to viper, the secret manager is called with static strings not referencing these env variables

 s.getSecret("SSOSyncSCIMAccessToken")

[ChrisPates]

Those four variables are stored in AWS Secrets Manager, to ensure security of the data. They are configurable without redeployment as they can be updated directly in AWS Secrets Manager, and SSOSync will use them on its next execution.

[Benbentwo]

Unfortunately, this is not resolved, the fact of the matter is that based on the latest version at this time (2.0.2) you are unable to deploy the release artifacts without the use of AWS Secrets Manager. This presents a problem in that you must use Secrets Manager as opposed to any other Secret Store.

This is a simple CLI that should be deployable anywhere via any methodology such as AWS Lambda, Kubernetes, or a simple bash script.

[ChrisPates]

The desire to be able to fetch sensative parameters from sources other than AWS Secrets Manager has been merged with related one under a single feature request [Expand the Options for storing the sensitive parameters to include binaray secrets and SSM Parameter Store #180](https://github.com/awslabs/ssosync/issues/180]. Please review and add any specific requirements you feel it doesn't address.