Remote access to T0, T1, and T2 with Bastion

[brooke-hamilton]

Benefit/Result/Outcome
So that I can have a secure terminal to log into the environment.

Description
Set up two jump boxes (Windows and Linux) in the SACA hub VNet, and configure Azure Bastion for remote access.

Acceptance Criteria

• One Windows and one Linux jump box are deployed to the SACA Hub VNet.
• Azure Bastion is set up and configured to connect to the jump boxes.
• Jump box authentication is local (not AAD), with credentials stored in KeyVault. The credentials are generated by the deployment.
• Deployment of the jump boxes and Bastion is optional, defaulted to deploy.
• Deployment of the jump boxes and Bastion can be done as a separate deployment step.
• Guidance on the approach is created in a markdown document, including the reason for choosing Bastion, why AAD authentication is not used on the jump boxes, and what customers should do if they want smart card authentication.

Out of scope:

• Apply STIGs and additional security configurations to the jump boxes, including forwarding logging to T1.
• Remote access to Tier 3 for workload owners. This solution will allow access to Tier 3, but is not the solution intended for Tier 3 workload owners. Tier 3 workload owners will configure their own solutions depending on their needs.

[jjansen23]

When/who creates the credentials that should be used to connect to the jump boxes ?
Are we're thinking to add this as input to the deployment process by specifying parameters ?
Is the thinking to use a specific password pattern based on the mlz name or any other known info?
When do these local creds expire, if at all ?
Will these keys be rotated to minimize exposures/breaches ?
Should we, at this time update the MLZ template to reflect the increase in cost to adding these services ? Currently it's measured around .
If deployment of the jump boxes and Bastion can be done as a separate deployment step, will it be as easy as running the deploy script with a parameter (like -bastion) - Striving for simplicity while complying with current deployment pattern. All this will be captured, in the guidance markdown document.
Are we set to support customers who lose/forget their local creds ? This may be a non-issue based on earlier questions.

[glennmusa]

Thanks for getting this up @brooke-hamilton!

I'll +1 these points @jjansen23 makes below

When/who creates the credentials that should be used to connect to the jump boxes?
Are we're thinking to add this as input to the deployment process by specifying parameters?

These two seem related.

• I think the immediate value is in generating these credentials for the user, providing it to the Terraform that creates the machine, and placing them in a Key Vault for later retrieval. There's good reference today in the azure-cli of how a secure password is generated.

• I think the nice to have is to be able to provide my own credential.

If deployment of the jump boxes and Bastion can be done as a separate deployment step, will it be as easy as running the deploy script with a parameter (like -bastion)

• I think the immediate value is in providing Bastion and the jumpboxes out of the box.

• The nice to have is the easy opt-out.

These two smell beyond the scope for today:

When do these local creds expire, if at all? Will these keys be rotated to minimize exposures/breaches?
Will these keys be rotated to minimize exposures/breaches?

And I think this would be overcome by managing the credential with KeyVault/deployment user having direct access to the resource:

Are we set to support customers who lose/forget their local creds? This may be a non-issue based on earlier questions.

[glennmusa]

• One Windows and one Linux jump box are deployed to the SACA Hub VNet.

Do we know of any universally available SKUs to use as a "baseline" between clouds?

[brooke-hamilton]

When/who creates the credentials that should be used to connect to the jump boxes?
Are we're thinking to add this as input to the deployment process by specifying parameters?

These two seem related.

• I think the immediate value is in generating these credentials for the user, providing it to the Terraform that creates the machine, and placing them in a Key Vault for later retrieval. There's good reference today in the azure-cli of how a secure password is generated.
• I think the nice to have is to be able to provide my own credential.

I updated the description to say that the credentials will be generated by the deployment.
I agree that it would be nice to be able to provide the desired user name.

[brooke-hamilton]

When do these local creds expire, if at all ?
Will these keys be rotated to minimize exposures/breaches ?

We will have a separate GH issue to cover additional security configuration. (And I think changing passwords is no longer recommended, but I'll defer to the work on that issue.)

[brooke-hamilton]

If deployment of the jump boxes and Bastion can be done as a separate deployment step, will it be as easy as running the deploy script with a parameter (like -bastion) - Striving for simplicity while complying with current deployment pattern. All this will be captured, in the guidance markdown document.

Yes 👍. The deployment of Bastion can be done as a separate step, and it will default to running as part of the main deployment. The only difference from what you said is that I think we would want to have a flag like --no-bastion to disable the Bastion deployment.

[brooke-hamilton]

Are we set to support customers who lose/forget their local creds ? This may be a non-issue based on earlier questions.

I don't know. Maybe we should do this as part of a separate issue.

If creds are lost, they can be found in KeyVault, so maybe it's not an issue. We may need guidance on changing a credential and adding new credentials.

[brooke-hamilton]

• One Windows and one Linux jump box are deployed to the SACA Hub VNet.

Do we know of any universally available SKUs to use as a "baseline" between clouds?

We will probably need to choose default SKUs for each cloud, and a default SKU if the cloud is something we haven't planned for.

[glennmusa]

Set up two jump boxes (Windows and Linux) in the SACA hub VNet, and configure Azure Bastion for remote access.

Ah, this also prompts @brooke-hamilton: are there machines deployed into the spokes that can be accessed via the Bastion jumpboxes -- or is that for another day?

[glennmusa]

Staged discrete tasks from this issue. Let me know your thoughts here or address scope in the individual issues as you see fit @brooke-hamilton @Breanna-Stryker @jjansen23 @Phydeauxman:

#186
#187
#188
#189
#190

Acceptance Criteria

• One Windows and one Linux jump box are deployed to the SACA Hub VNet. Provision a Windows VM as a Bastion jumpbox #187, Provision a Linux VM as a Bastion jumpbox #188
• Azure Bastion is set up and configured to connect to the jump boxes. An Azure Bastion module that can be added to a virtual network #186, Provision a Windows VM as a Bastion jumpbox #187, Provision a Linux VM as a Bastion jumpbox #188
• Jump box authentication is local (not AAD), with credentials stored in KeyVault. The credentials are generated by the deployment. Store virtual machine login credentials in a KeyVault #190
• Deployment of the jump boxes and Bastion is optional, defaulted to deploy. Provide a way to optionally deploy Bastion host and jumpboxes in the Hub network #189
• Deployment of the jump boxes and Bastion can be done as a separate deployment step. Provide a way to optionally deploy Bastion host and jumpboxes in the Hub network #189
• Guidance on the approach is created in a markdown document, including the reason for choosing Bastion, why AAD authentication is not used on the jump boxes, and what customers should do if they want smart card authentication.

[brooke-hamilton]

Closing this issue because it was decomposed into the items above.