mirror of https://github.com/hashicorp/boundary
docs: Version 0.20.0 docs (#6085)
* Update documentation to include RDP in credential injection * Update FAQ on Boundary and Vault integration Fixed typo. * update documentation on credential stores and workflows for RDP * update static credential store documentation to include upd credential creation * update documentation for credential injection setup * Update 'credentials create' command documentation for upd credential type * fixed typo in UPD options * Update create.mdx with instructions for RDP targets * Create rdp-testing-and-compatibility-matrix.mdx * Update rdp-testing-and-compatibility-matrix.mdx * Update rdp-testing-and-compatibility-matrix.mdx * Update to mention ldap secrets engine * Update rdp-testing-and-compatibility-matrix.mdx to get rid of ticket number * updated to include mention of vault kv and chad suggestions Updated with Chad's suggestions and vault kv * Update rdp-testing-and-compatibility-matrix.mdx Found another place where I neglected the vault kv * docs: Style updates * docs: Clean up beta references, adds update commands * docs: Edits, update domain model topics * docs: Add target address caveats * docs: Edit network config section * docs: Use custom port number to connect * docs: Adds anchor link, beta tag * docs: Respond to feedback * docs: Cleanup for consistency, remove known issue * docs: Cleanup and minor fixes * docs: Add link to create issue * docs: Add direct address note to targets CLI topics * Update website/content/docs/concepts/credential-management.mdx Co-authored-by: Irena Rindos <irenarindos@users.noreply.github.com> * docs: Remove beta references from target and credentials * docs: Remove Vault cred store ID * docs: Remove SSH cert from brokered creds * docs: Remove session recording options * docs: Adds UPD to credential stores domain model topic * Update website/content/docs/credentials/rdp-testing-and-compatibility-matrix.mdx Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> * Update website/content/docs/credentials/rdp-testing-and-compatibility-matrix.mdx Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> * docs: Remove session recording options * docs: Update limitations and configuration * Update website/content/docs/credentials/configure-credential-injection.mdx Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> * docs: Update default port commands * docs: Add known issue for error * docs: Fix typo * Update website/content/docs/credentials/rdp-testing-and-compatibility-matrix.mdx Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> * docs: Add certificate acceptance to Windows * docs: Reorder UPD options * docs: Add NTLMV2 to cred management statement * docs: Update Windows Remote Desktop Connection error * docs: Clarify domain behavior * docs: Fix back ticks on command options * docs: Update command format in definition * docs: Clarify port conflict with Remote Desktop app * docs: Update RDP target address caveat * docs: Release notes 0.20.0 * docs: Minor edit * docs: Vercel build * docs: Deletes older important changes --------- Co-authored-by: Dan Rohan <daniel.rohan@elastic.co> Co-authored-by: Dan Rohan <dan.rohan@hashicorp.com> Co-authored-by: Irena Rindos <irenarindos@users.noreply.github.com> Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>pull/6089/head
parent
8d158e7dd4
commit
4ffb21f9ca
@ -0,0 +1,203 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: RDP credential injection compatibility
|
||||
description: >-
|
||||
Learn about what is supported and understand known limitations for the beta version of the RDP credential injection feature.
|
||||
---
|
||||
|
||||
# RDP credential injection compatibility
|
||||
|
||||
@include 'alerts/beta.mdx'
|
||||
|
||||
RDP credential injection is currently in **beta**. This feature is under active development and testing.
|
||||
|
||||
**Important considerations:**
|
||||
|
||||
- The [compatibility matrix](#compatibility-status) below reflects currently tested configurations.
|
||||
- Additional client/target combinations are being validated and will be added regularly.
|
||||
- Some functionality may change before general availability.
|
||||
- Please report any issues or untested combinations through [official support channels](https://support.hashicorp.com).
|
||||
- [Create an issue](https://github.com/hashicorp/boundary/issues/new/choose) to send the Boundary team feedback about the beta.
|
||||
|
||||
This documentation will be updated frequently as new combinations are tested and validated.
|
||||
|
||||
**Key takeaways for the RDP credential injection beta:**
|
||||
|
||||
- **Credential source:** The initial beta only supports static credentials from Boundary's built-in **static credential store** or Vault's Key Value store.
|
||||
- **Supported authentication:** Only **Kerberos** and **NTLMv2** are supported.
|
||||
- **Unsupported authentication:** Microsoft Entra ID, passwordless methods (Windows Hello, FIDO2), and Smart Cards are **not** supported.
|
||||
- **Transparent sessions:** RDP transparent sessions on Windows clients require a custom port configuration due to a conflict with the default port `3389`. Refer to [Using transparent sessions with RDP on Windows](#using-transparent-sessions-with-rdp-on-windows) for two possible workarounds.
|
||||
- **Initial connection:** Users must manually accept a self-signed certificate on their first connection to a target. Some clients prompt users for a username and password even when credential injection is in use, but Boundary ignores the entries. You can enter anything and Boundary uses the configured injected credential to authenticate to the target.
|
||||
- **Important configuration note:** If you use the Windows RDP client and set the `connection limit` to `1` for RDP targets it will cause all RDP connections to fail. You can leave the connection limit unset or configure a limit of 2 or higher to account for the multiple connections used by the RDP client.
|
||||
|
||||
## How credential injection works
|
||||
|
||||
When users connect to RDP targets, Boundary can automatically inject credentials, preventing exposure to the end-user. This is the most secure workflow, providing a passwordless experience within the supported authentication frameworks.
|
||||
|
||||
Boundary retrieves credentials from a supported credential store and injects them directly into the RDP session on behalf of the user. **The initial beta release only supports static credentials from Boundary's built-in static credential store or Vault's KV store.** Support for the Vault LDAP Secrets Engine, is planned as a fast-follow release.
|
||||
|
||||
Refer to [Credential injection](/boundary/docs/concepts/credential-management#credential-injection) for more information about how credential injection works in Boundary.
|
||||
|
||||
### Supported authentication methods
|
||||
|
||||
As of Boundary 0.20, we **only** support the following traditional authentication methods for RDP targets:
|
||||
|
||||
1. **Kerberos authentication** - The primary method for domain-joined Windows servers.
|
||||
1. **NTLMv2 authentication** - Used for standalone servers or as a fallback.
|
||||
|
||||
<Note>
|
||||
|
||||
Modern and cloud-based authentication methods are **not supported** at this time. This includes, but is not limited to:
|
||||
|
||||
- Microsoft Entra ID (formerly Azure Active Directory)
|
||||
- Passwordless methods (Windows Hello, FIDO2 keys)
|
||||
- Certificate-based authentication (including Smart Cards)
|
||||
|
||||
</Note>
|
||||
|
||||
## Known limitations
|
||||
|
||||
The following issues may affect RDP connections, particularly when using transparent sessions:
|
||||
|
||||
- **Concurrent transparent sessions hanging:** Attempting to launch more than one concurrent transparent session for RDP will cause the Boundary desktop client to hang silently. You must fully terminate the first session before starting another.
|
||||
- **Improper session termination:** Closing the RDP client window does not always properly terminate the underlying Boundary session. This can prevent new connections and contributes to the hanging issue described above.
|
||||
- **Transparent sessions on Windows:** Transparent sessions for RDP do not work out-of-the-box on modern Windows clients (Windows 11+, Windows Server 2025) due to a port conflict. Refer to [Using transparent sessions with RDP on Windows](/boundary/docs/credentials/rdp-testing-and-compatibility-matrix#using-transparent-sessions-with-rdp-on-windows) for two possible workarounds.
|
||||
- **Error during basic settings exchange:** When you connect to an RDP target using the built-in Windows Remote Desktop Connection app, it creates the following error:
|
||||
|
||||
`rdp.handleProxy:error during basic settings exchange`
|
||||
|
||||
The error has no impact on the connection, it is a known issue.
|
||||
|
||||
## Configuration requirements
|
||||
|
||||
Refer to the following sections for specific configuration requirements for the RDP credential injection beta.
|
||||
|
||||
### Using transparent sessions with RDP on Windows
|
||||
|
||||
Due to a port conflict with the Windows Remote Desktop Connection app on modern Windows operating systems (Windows 11+, Windows Server 2025), transparent sessions fail when you use the default port (`3389`) to establish an RDP connection.
|
||||
The port conflict is an issue even if you enable Remote Desktop.
|
||||
This issue prevents users from establishing transparent sessions by entering a target alias in their RDP client.
|
||||
|
||||
To connect to an RDP target using a transparent session from a Windows client, you **must** use a custom port. Two primary workarounds are available:
|
||||
|
||||
1. **Configure a default client port:** Set a custom port (e.g., `83389`) in the target's configuration within Boundary. The user must then connect by specifying this port in their RDP client (for example, `my-server:83389`).
|
||||
1. **Use `.rdp` bookmark files:** Create and distribute an `.rdp` file that contains the full connection string, including the custom port for the localhost listener (for example, `full address:s:localhost:51129`). Bookmark files allow users to connect by simply opening the file.
|
||||
|
||||
### Certificate handling
|
||||
|
||||
Boundary generates self-signed certificates for each RDP target. When users first connect to a target, they must manually accept the certificate. This is a one-time action per target for most clients, though behavior varies:
|
||||
|
||||
- **Windows clients** remember certificates across sessions.
|
||||
- **macOS clients** require accepting certificates per alias or endpoint.
|
||||
- **Custom listen addresses** generate certificate mismatch warnings.
|
||||
|
||||
Future releases may support enterprise certificate authorities for trusted certificates.
|
||||
|
||||
### Connection limits
|
||||
|
||||
The Windows Remote Desktop Connection application consumes multiple connections when initiating a session.
|
||||
|
||||
If you set the connection limit to `1` for RDP targets it will cause all RDP connections using this client to fail. You can leave the connection limit unset or configure a limit of 2 or higher to account for the multiple connections used by the RDP client.
|
||||
|
||||
### Network configuration
|
||||
|
||||
RDP credential injection has specific network requirements:
|
||||
|
||||
- UDP transport is disabled.
|
||||
- Server redirection is not supported.
|
||||
- The maximum TLS version is 1.2. TLS 1.3 is incompatible with Windows Server 2025.
|
||||
|
||||
### Client behavior
|
||||
|
||||
Different RDP clients exhibit unique behaviors:
|
||||
|
||||
**Windows Remote Desktop Connection:**
|
||||
- Does not prompt for credentials when Boundary injects them.
|
||||
- Requires manual certificate acceptance per endpoint.
|
||||
|
||||
**macOS Windows App:**
|
||||
- Prompts for credentials, but Boundary ignores the entries. Boundary uses the configured injected credential to authenticate to the target.
|
||||
- Requires manual certificate acceptance per endpoint.
|
||||
|
||||
## Compatibility status
|
||||
|
||||
Refer to the following sections for information about which Windows versions the beta RDP credential injection feature is compatible with.
|
||||
|
||||
The tables below use the following to indicate compatiblity:
|
||||
|
||||
- **✅:** Tested and verified to be compatible.
|
||||
- **Pending:** Validation is planned but not yet complete.
|
||||
|
||||
### Windows Server 2025
|
||||
|
||||
| Client OS | Kerberos only | Kerberos + NTLMv2 (domain-joined worker) | Kerberos + NTLMv2 (non-domain worker) |
|
||||
|-----------|:-------------:|:----------------------------------------:|:--------------------------------------:|
|
||||
| Windows 11 | Pending | ✅ | Pending |
|
||||
| Windows 10 | ✅ | Pending | Pending |
|
||||
| macOS 15 | Pending | Pending | Pending |
|
||||
| macOS 14 | Pending | Pending | Pending |
|
||||
| macOS 13 | Pending | Pending | Pending |
|
||||
|
||||
### Windows Server 2022
|
||||
|
||||
| Client OS | Kerberos only | Kerberos + NTLMv2 (domain-joined worker) | Kerberos + NTLMv2 (non-domain worker) |
|
||||
|-----------|:-------------:|:----------------------------------------:|:--------------------------------------:|
|
||||
| Windows 11 | ✅ | ✅ | ✅ |
|
||||
| Windows 10 | ✅ | ✅ | ✅ |
|
||||
| macOS 15 | Pending | ✅ | ✅ |
|
||||
| macOS 14 | Pending | Pending | Pending |
|
||||
| macOS 13 | Pending | Pending | Pending |
|
||||
|
||||
### Windows Server 2019
|
||||
|
||||
| Client OS | Kerberos only | Kerberos + NTLMv2 (domain-joined worker) | Kerberos + NTLMv2 (non-domain worker) |
|
||||
|-----------|:-------------:|:----------------------------------------:|:--------------------------------------:|
|
||||
| Windows 11 | ✅ | ✅ | ✅ |
|
||||
| Windows 10 | ✅ | ✅ | ✅ |
|
||||
| macOS 15 | ✅ | ✅ | ✅ |
|
||||
| macOS 14 | Pending | Pending | Pending |
|
||||
| macOS 13 | Pending | Pending | Pending |
|
||||
|
||||
### Windows Server 2016
|
||||
|
||||
| Client OS | Kerberos only | Kerberos + NTLMv2 (domain-joined worker) | Kerberos + NTLMv2 (non-domain worker) |
|
||||
|-----------|:-------------:|:----------------------------------------:|:--------------------------------------:|
|
||||
| Windows 11 | Pending | ✅ | ✅ |
|
||||
| Windows 10 | ✅ | ✅ | Pending |
|
||||
| macOS 15 | ✅ | ✅ | ✅ |
|
||||
| macOS 14 | Pending | Pending | Pending |
|
||||
| macOS 13 | Pending | Pending | Pending |
|
||||
|
||||
## Quick troubleshooting and FAQ
|
||||
|
||||
**Q: Can I use credentials from my Vault LDAP engine or Active Directory for this feature?**
|
||||
|
||||
A: Not yet. The initial beta only supports credentials stored in Boundary's static credential store and the Vault K/V store. Support for the Vault LDAP Secrets Engine is a high-priority addition planned for a fast-follow release.
|
||||
|
||||
**Q: Why am I getting a certificate warning when I connect?**
|
||||
|
||||
A: This is expected behavior. Boundary generates a self-signed certificate for each RDP target. You must accept this certificate on your first connection.
|
||||
|
||||
**Q: My connection is failing immediately. What should I check first?**
|
||||
|
||||
A: Check the `connection limit` on your target. It cannot be set to `1`. Leave it unset, or set it to 2 or higher.
|
||||
|
||||
**Q: Why can't I connect to my RDP transparent session on Windows by just using its name?**
|
||||
|
||||
A: Modern Windows versions block local applications from using the default RDP port (3389). You must use a workaround, such as connecting to a custom port or using a pre-configured `.rdp` file. Refer to [Using transparent sessions with RDP on Windows](#using-transparent-sessions-with-rdp-on-windows).
|
||||
|
||||
**Q: My desktop client hung after I tried to open a second RDP session. What do I do?**
|
||||
|
||||
A: This is a known issue. The client currently does not support more than one concurrent RDP transparent session. You must ensure your first session is completely terminated before starting a new one.
|
||||
|
||||
**Q: Does this work with servers that require Entra ID login?**
|
||||
|
||||
A: No. At this time, only servers using traditional Kerberos or NTLMv2 authentication are supported.
|
||||
|
||||
**Q: The macOS RDP client is asking for a password. Is injection not working?**
|
||||
|
||||
A: This is a known behavior of the macOS client. You can leave the password field blank and proceed; Boundary will still inject the correct credentials in the background.
|
||||
|
||||
## More information
|
||||
|
||||
For more information about how Boundary manages credentials, refer to [Credentials in Boundary](/boundary/docs/credentials).
|
||||
@ -0,0 +1,212 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: v0.20.0 release notes
|
||||
description: >-
|
||||
Learn more about the new features included in the Boundary 0.20.0 release. Understand any deprecations, changes, and known issues.
|
||||
---
|
||||
|
||||
# Boundary 0.20.0 release notes
|
||||
|
||||
**GA date:** September 25, 2025
|
||||
|
||||
@include 'release-notes/intro.mdx'
|
||||
|
||||
## Important changes
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th style={{verticalAlign: 'middle'}}>Change</th>
|
||||
<th style={{verticalAlign: 'middle'}}>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
|
||||
<tr>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
Error when sending requests to aliases using HCP Boundary
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
A known issue that was caused by the way default grants were previously configured in HCP Boundary could cause you to receive 500 errors when you attempted to list resolvable aliases. The issue has been resolved. Any clusters that you created on or after April 26, 2025 should not have the issue.
|
||||
<br /><br />
|
||||
You can add grants to resolve the error for any older clusters that exhibit this behavior.
|
||||
<br /><br />
|
||||
Learn more: <a href="#hcp-grants">Known issues and breaking changes </a>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
Boundary client version number realignment
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
Previously, the Boundary Client Agent and installer used a numbering scheme that was inconsistent with Boundary's release numbers. This inconsistency could make it difficult to understand version support and compatibility.
|
||||
<br /><br />
|
||||
On May 27, 2025 new versions of the Boundary Client Agent and installer were released with a new numbering scheme that more closely follows Boundary's release numbers. Those versions were released as 0.19.5 to match the major Boundary version 0.19.x. Going forward, the Client Agent and installer will use the same major number as the current Boundary release. Any patches or updates will be reflected in the minor number.
|
||||
<br /><br />
|
||||
Learn more about control plane and client compatibility: <a href="/boundary/docs/enterprise/supported-versions">Boundary Enterprise supported versions policy </a>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
Redundant grant scopes are no longer permitted
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
You may have redundant grant scopes if you applied a grant to a scope and the scope also inherited the grant from the <code>this</code>, <code>children</code>, or <code>descendants</code> options. As of Boundary version 0.19.3, redundant grant scopes are no longer permitted.
|
||||
<br /><br />
|
||||
When you upgrade a Boundary Enterprise or Community edition cluster to version 0.19.3 or later, the migration will fail with a message if the database contains any redundant grant scopes. The migration tool provides a command that automatically removes any redundant grant scopes so that you can proceed with the upgrade.
|
||||
<br /><br />
|
||||
For HCP Boundary users, the redundant grant scopes are automatically removed as part of the migration process.
|
||||
<br /><br />
|
||||
Learn more about removing redundant grant scopes and upgrading to version 0.19.3 or later: <a href="#redundant-grants">Known issues and breaking changes </a>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## New features
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th style={{verticalAlign: 'middle'}}>Feature</th>
|
||||
<th style={{verticalAlign: 'middle'}}>Update</th>
|
||||
<th style={{verticalAlign: 'middle'}}>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
|
||||
<tr>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
RDP targets
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
GA
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
Boundary now supports a new RDP target type. RDP targets let you use injected credentials to authenticate an RDP session between the client and end host in Windows environments that use Active Directory authentication. RDP targets use the new username password domain credential type.
|
||||
<br /><br />
|
||||
Learn more: <a href="/boundary/docs/domain-model/targets#target-types">Target types</a> and <a href="/boundary/docs/commands/targets/create">targets create command</a>.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
Username password domain credentials
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
GA
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
There is a new username password domain credential type for Windows environments that use Active Directory authentication. You can use username password domain credentials for credential injection when you connect to an RDP target.
|
||||
<br /><br />
|
||||
Learn more: <a href="/boundary/docs/concepts/credential-management">Credential management</a>, <a href="/boundary/docs/credentials">Credentials in Boundary</a>, and <a href="/boundary/docs/commands/credentials/create">credentials create command</a>.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
RDP credential injection
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
BETA
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
Boundary now supports RDP credential injection as a beta feature. When users connect to RDP targets, Boundary can automatically inject credentials into the RDP session on behalf of the user.
|
||||
<br /><br />The initial beta release supports static credentials from Boundary's built-in static credential store or Vault's KV store. Refer to the documentation for known limitations, configuration requirements, and Windows compatibility.
|
||||
<br /><br />
|
||||
Learn more: <a href="/boundary/docs/credentials/rdp-testing-and-compatibility-matrix">RDP credential injection compatibility</a>.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Known issues and breaking changes
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th style={{verticalAlign: 'middle'}}>Version</th>
|
||||
<th style={{verticalAlign: 'middle'}}>Issue</th>
|
||||
<th style={{verticalAligh: 'middle'}}>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
|
||||
<tr>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
0.13.0+
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
Rotation of AWS access and secret keys during a session results in stale recordings
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
In Boundary version 0.13.0+, when you rotate a storage bucket's secrets, any new sessions use the new credentials. However, previously established sessions continue to use the old credentials.
|
||||
<br /><br />
|
||||
As a best practice, administrators should rotate credentials in a phased manner, ensuring that all previously established sessions are completed before revoking the stale credentials.
|
||||
Otherwise, you may end up with recordings that aren't stored in the remote storage bucket, and are unable to be played back.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
0.13.0+
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
Unsupported recovery workflow during worker failure
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
If a worker fails during a recording, there is no way to recover the recording. This could happen due to a network connectivity issue or because a worker is scaled down, for example.
|
||||
<br /><br />
|
||||
Learn more:
|
||||
<a href="/boundary/docs/troubleshoot/troubleshoot-recorded-sessions#unsupported-recovery-workflow">Unsupported recovery workflow</a>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
0.17.1+
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
Docker image no longer contains <code>curl</code>
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
As of version 0.17.1 and later, the <code>curl</code> binary is no longer included in the published Docker container image for Boundary.
|
||||
<br /><br />
|
||||
The image now includes <code>wget</code>. You can use <code>wget</code> to check the health endpoint for workers.
|
||||
<br /><br />
|
||||
Learn more: <a href="/boundary/docs/operations/health#check-the-health-endpoint-using-wget">Check the health endpoint using <code>wget</code></a>
|
||||
<br /><br />
|
||||
If your workflow depends on having <code>curl</code> in the image, you can dynamically install it using <code>apk</code>. Refer to the following commands for examples of using <code>apk</code> to install <code>curl</code>:
|
||||
<br /><br />
|
||||
<code><CONTAINER-ID> apk add curl</code>
|
||||
<br /><br />
|
||||
or
|
||||
<br /><br />
|
||||
<code>kubectl exec -ti <NAME> -- apk add curl</code>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
0.18.x+
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
Boundary version 0.18.x and later CLI is unable to establish connections using the <code>boundary connect</code> command
|
||||
</td>
|
||||
<td style={{verticalAlign: 'middle'}}>
|
||||
Boundary version 0.18.x uses Go version 1.23, which introduced a new TLS handshake behavior. Some VPN providers struggle with the TLS handshake being sent over 2 frames instead of 1, which can lead to Boundary version 0.18.x and later controllers, workers, or clients being unable to establish connections. As a workaround, you can revert back to the previous TLS handshake behavior.
|
||||
<br /><br />
|
||||
To revert back to the previous TLS handshake behavior, add the <code>tlskyber=0</code> parameters to the GODEBUG environment variable before the <code>boundary connect</code> command. For example:
|
||||
<br /><br />
|
||||
<code>GODEBUG=tlskyber=0 boundary connect ssh -target-id <ID></code>
|
||||
<br /><br />
|
||||
Learn more: <a href="https://github.com/golang/go/issues/70047">Go issue #70047</a> and <a href="https://tip.golang.org/doc/go1.23">Go 1.23 Release Notes</a>
|
||||
<br /><br />
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
Loading…
Reference in new issue