However, Terraform installs a separate cache of plugins and modules for each working directory, so maintaining multiple directories can waste bandwidth and disk space. You can create multiple working directories to maintain multiple instances of a configuration with completely separate state data. For example, you might deploy test infrastructure to a different region.
When you provision infrastructure in each workspace, you usually need to manually specify different input variables to differentiate each collection. This includes provisioning and state manipulation. Most Terraform commands only interact with the currently selected workspace. For a given working directory, you can only select one workspace at a time. Use the terraform workspace select command to change the currently selected workspace. Use the terraform workspace list, terraform workspace new, and terraform workspace delete commands to manage the available workspaces in the current working directory. Managing CLI WorkspacesĮvery initialized working directory starts with one workspace named default. We recommend using alternative approaches for complex deployments requiring separate credentials and access controls. Workspaces can be helpful for specific use cases, but they are not required to use the Terraform CLI. When you run the same configuration multiple times with separate state data, Terraform can manage multiple sets of non-overlapping resources. Terraform relies on state to associate resources with real-world objects.
They are distinctly different from workspaces in Terraform Cloud, which each have their own Terraform configuration and function as separate working directories. In your Okta org, configure the Amazon WorkSpaces application and required factors.Īmazon WorkSpaces must be configured for MFA.ĪWS WorkSpace users are managed in Active Directory but must be provisioned into Okta.Workspaces in the Terraform CLI refer to separate instances of state data inside the same Terraform working directory.
WORKSPACES AWS INSTALL
Preconfigure Amazon WS instances with required Active Directory, EC2 and workspace.ĭownload and install the Okta RADIUS agent on Instance B.įor throughput, availability and other considerations, see Okta RADIUS Server Agent Deployment Best Practices.Ĭreate inbound rules to allow the RADIUS agent to communicate with an AWS Directory Service instance. When an end user that's enrolled in Okta with DUO MFA attempts to access Amazon Workspaces configured with RADIUS, they must provide the six digit MFA passcode displayed on the DUO mobile app in addition to their primary password. If that private IP changes the AWS Directory MFA configuration must be updated to reflect the new private IP.ĭUO MFA with Push/SMS/Call isn't supported for Amazon Workspaces with RADIUS. The AWS Directory service requires the private IP address of Instance B to delegate the MFA challenge over RADIUS. Directory ID is used to determine the name of the Security Group. You must have the Directory ID of the AWS Directory Service. The AWS Directory Service requires the private IP address of Instance B to delegate the MFA challenge over RADIUS.ĪWS Directory Service instance, configured and pointing to Instance A, running Active Directory.
WORKSPACES AWS WINDOWS
Instance B: represents the Windows 2012r2 host on which to install the Okta RADIUS agent.Instance A: represents the Amazon Directory Service virtual machine instance.In addition, you must configure Amazon Web Services as: In addition, you must configure Amazon Web Services as:Īmazon Web Services instances, configured as: RADIUS traffic between the gateway (client) and the RADIUS agent (server). (Default, you can change this when you install and configure the RADIUS app) Meet the following network connectivity requirements before you install the Okta RADIUS agent: SourceĬonfiguration and authentication traffic.
0 kommentar(er)
