GCP Certificate Authority Service Integration for RDP
Last modified on July 30, 2024
This feature is part of the Enterprise plan. If it is not enabled for your organization, please contact StrongDM at the StrongDM Help Center.
This guide provides general information on how to add a certificate authority (CA) issued by Google Certificate Authority Service (CAS), a third-party PKI service for Google Cloud Platform (GCP), as a third-party CA to StrongDM.
GCP Certificate Authority Service CA integration allows a Google CAS CA to be used, instead of the default Strong CA managed by StrongDM, for certificate authentication for RDP using Identity Aliases or leased credentials in a Microsoft Active Directory (AD) deployment.
Prerequisites
Before you begin, ensure that you have the following.
- Administrator permission level in StrongDM
- StrongDM gateway or relay that can access the Google CAS service endpoint
https://privateca.googleapis.com/
- Familiarity with Google CAS, CA pools, and Microsoft AD
- Properly configured CA in Google CAS
- Certificate Revocation List (CRL) must accessible by the Active Directory domain controller for the target AD deployment.
http://privateca-content-*.storage.googleapis.com/*/crl.crl
, where wildcards represent the unique IDs of the CRL generated by Google CAS. To find the CRL address, you can request a certificate from a CA using the Google CLI or the Google Cloud console, and examine the CRL distribution point on the issued certificate. This will be the CRL distribution point for the given CA.Google CAS Configuration Considerations
This section briefly describes the most important parts of Google CAS setup to consider when integrating a CA with StrongDM.
CA structure
Google CAS is structured to host CA certificates in load-balanced CA pools. A CA pool can contain any number of root and subordinate CA certificates. Issued certificates can be requested from individual CAs or from a CA pool.
CAs in a pool need not all be root CAs, as long as each CA that will be used for certificate authentication is added to your AD deployment as a trusted root CA.
If a CA pool has multiple certificates that are part of the same trust chain, all CAs in a trust chain need to be uploaded in order for all CAs (root and intermediate) to be usable for certificate authentication into AD.
CA settings
This CA supports only enterprise-tier CAs for RDP authentication.
In the Google Cloud console, the “Publish CRL to GCS bucket for CAs in this pool” setting is enabled on all CAs within a CA pool and cannot be toggled on/off for individual CAs within a pool when the setting is enabled.
TTL
The certificate time-to-live (TTL) determines the lifetime of all certificates generated by the CA. The TTL may be set in either Google Cloud or StrongDM when adding the GCP CA (see the Certificate TTL Minutes property). In StrongDM, the default certificate TTL is five minutes. In Google Cloud, you can set the maximum TTL for certificates issued from any CA in a particular CA pool via the Google Cloud console or Google Cloud CLI.
If set to anything other than the default in StrongDM, and if the TTL set in StrongDM is less than the maximum already set, the TTL of the issued certificate will be used.
Setting the TTL on a CA in StrongDM that only has a CA pool ID (and no specific CA ID) will result in all certificates issued from the CA pool for RDP authentication with StrongDM to have the TTL that is set via StrongDM.
Authentication from a StrongDM gateway or relay to Google CAS
The gateway or relay must be able to reach out to Google CAS for a certificate. The authenticated user or service account must have the correct permissions to request a certificate from Google CAS.
For a service account access key, you will need to do the following:
- Create an IAM service account with permissions to request certificates
- Create an access key for the service account
- Transfer the access key file to relay and run
gcloud auth login --cred-file=KEY_FILE
For other authentication options, such as user authentication or service account impersonation, consult the GCP documentation.
Service limit quotas for GCP
Note that Google CAS places a quota on how many certificates can be requested per second (7 requests per second per CA, and 100 requests per second per location per project).
Certificate Signing Requests
How does certificate signing work? StrongDM generates a key pair on the gateway or relay and generates a CSR signed by the private key. The CSR is submitted to Google CAS for signing. The resulting signed certificate is then used, along with the private key, to authenticate to the target resource. The private key never leaves the gateway or relay where it was created.
Add GCP CA in the Admin UI
To add a GCP CA in the Admin UI, follow these steps.
- From the Settings > Credentials Management page in the Certificate Authorities tab, click Add certificate authority.
- Enter the Name for the CA (any name).
- For Type, select GCP Certificate Authority Service RDP.
- The form updates with other CA properties. Complete all required properties.
- Click Create certificate authority.
GCP Certificate Authority Service RDP properties
The following properties are for GCP Certificate Authority Service RDP.
Property | Requirement | Description |
---|---|---|
Project ID | Required | Project ID (for example, my-gcp-project ) |
Location | Required | Location (for example, us-east1 ) |
Certificate Authority Pool ID | Required | CA pool ID (for example, my-gcp-pool-id ) |
Certificate Authority ID | Optional | Individual CA ID (for example, my-certificate-authority-id ); optionl only if, for a given CA pool, all CAs in that pool are added as a trusted CA in your AD deployment; in such circumstances, certificate requests made to this pool will be load balanced by GCP to request from different CAs |
Certificate TTL Minutes | Required | TTL of the issued certificate, in minutes (for example, 480 ); default is 5 ; if not specified, the default TTL of five minutes is used |
All third-party CAs except for AD CS and Keyfactor EJBCA have a default TTL of five minutes. A five-minute TTL ensures short-lived certificates so that authentications can’t be reused beyond the specified TTL. If you wish to have a longer TTL, please set it appropriately for your organization and consult your CA service provider and CA administrator.
Please note that in the Vault signing role, max_ttl
sets the maximum TTL for certificates issued by the CA. If that is set and if a value is also specified for Certificate TTL Minutes in StrongDM, the resulting TTL is the lower of the two values. See the CA settings section of this guide for more information.
Add the GCP CA to a Certificate-Based RDP Server
- If you have not already done so, follow the instructions to add an RDP server with certificate authentication.
- On the resource form, pay particular attention to Certificate Authority. For this field, select the newly added GCP CA.
- Complete all required fields and save.
- Test the connection to the resource (for example, use Remote Desktop to connect).
Manage the CA
After you have added the GCP CA and set a certificate-based server to use it, you may manage the CA and review its settings on the Certificate Authorities tab of the Settings > Credentials Management page in the Admin UI. You may select the CA from the list or click its Details button to view diagostics, update its settings, or delete the CA configuration.
The Diagnostics tab shows all the nodes (gateways and relays) that are configured to access the CA, as well as health information for the nodes.
If the CA is unable to be accessed by any gateway or relay, please review the CA’s Settings tab and make sure the CA credentials are correct.
Additional Information
Third-party CAs also may be added and managed in the CLI, SDKs, and Terraform. Note that third-party CAs are treated like secret stores in the CLI, SDKs, and Terraform. As such, they use secret store commands, domain objects, and resources.
API Account example-terraform-key (cc1e23eb-e456-7891-23c4-edf5678c9123) created a secret store named example-tf-rdp-ca
.Add GCP CA in the CLI
To add a GCP CA in the CLI instead of the Admin UI, use the sdm admin secretstores create gcpCertX509 CLI command. The secret store type GCPCertX509Store
corresponds to the GCP Certificate Authority Service RDP CA type.
In the CLI, the options are the same as the GCP Certificate Authority Service RDP CA properties set in the Admin UI.
CLI example
# Create GCP Certificate Authority Service RDP CA
sdm admin secretstores create gcpCertX509
--name="Example GCP CA"
--ca-id="12345678-a0b-123"
--ca-pool-id="example-ca-pool"
--location value="us-west2"
--project-id="example-project-id"
--issued-cert-ttl-minutes="480"
# Create RDP (Certificate Based) server
sdm admin servers create rdp-cert
--name="Example RDP GCP"
--hostname="https://gcp.example.com:1234"
--secret-store-id="se-e1b2"
--username="username"
# Run secret store healthcheck
sdm admin secretstores healthcheck se-e1b2
# Check that the secret store is reachable
sdm admin secretstores status
# Check the connection to the resource
sdm connect "Example RDP GCP"
Add GCP RDP CA in Terraform
In addition to using the Admin UI and CLI, you may use Terraform to add a GCP CA for use with certificate-based RDP servers. This section includes a Terraform example.
For additional information, see our Terraform provider documentation.
Terraform example
# Install StrongDM provider
terraform {
required_providers {
sdm = {
source = "strongdm/sdm"
version = "7.1.1"
}
}
}
# Configure StrongDM provider
provider "sdm" {
# Add API access key and secret key from Admin UI
api_access_key = "njjSn...5hM"
api_secret_key = "ziG...="
}
variable "prefix" {
type = string
default = "example-tf-"
}
# Create GCP RDP CA
resource "sdm_secret_store" "example-tf-rdp-ca" {
gcp_token_cert_x509 {
name = "${var.prefix}gcp-ca"
ca-id = "12345678-a0b-123"
ca-pool-id = "example-ca-pool"
location value = "us-west2"
project-id = "example-project-id"
issued_cert_ttl_minutes = "480"
}
}
# Create RDP (Certificate Based) server
resource "sdm_resource" "example-rdp-cert-based" {
rdp {
name = "${var.prefix}rdp-gcp-ca"
hostname = "https://gcp.example.com:1234"
secret_store_id = sdm_secret_store.example-tf-rdp-ca.id
username = "username"
}
}
Add GCP CA with the SDKs
To add a GCP CA with the StrongDM SDKs, please see the SDKs on GitHub: