# xdr customer portal instances

Builds and configures the instances that host the customer portal website. NOTE: the grain ec2_tags:Name and the pillar aws_registry_account are required for portal salt state to complete successfully. 

New Portal Server setup steps 
- test.version   				# are we on the correct salt version?
- saltutil.sync_all             
- saltutil.refresh_modules      # refresh grains
- saltutil.refresh_pillar       # refresh pillars
- pillar.get aws_registry_account  # This one is needed
- slsutil.renderer salt://docker/portal.sls # Does this render properly?
- grains.get environment 		# make sure "test" is present
- state.sls os_modifications 	# get some base stuff out of the way
- grains.get ec2_tags:Name 			# make sure customer-portal is present for highstate to work
- state.highstate               # push everything including docker and docker images

## Vault Auth Issues

HELP! I destroyed then recreated the AWS IAM Portal Role and now Vault will not let me log in!!

In Vault disable the auth method
`vault auth disable aws`

Then in terraform reapply the config. 
`VAULT_TOKEN=<fromvault> TF_VAR_okta_api_token=YOURTOKENHERE TF_VAR_okta_oidc_client_secret=YOURSECRETHERE terragrunt-local apply -target=vault_auth_backend.aws -target=vault_aws_auth_backend_client.aws -target=vault_aws_auth_backend_role.portal`

Vault apparently caches the AWS response for the portal IAM role. 

https://blog.gruntwork.io/a-guide-to-automating-hashicorp-vault-3-authenticating-with-an-iam-user-or-role-a3203a3ee088 
It is important to note that although the Vault Role is configured with the IAM principal ARN, what Vault actually checks against is a unique internal ID from AWS. So if you destroy and recreate your IAM Role, Vault will reject the login attempt.