CockroachDB 2.1.4 accepts session tokens for S3 storage

A temporary credential needs to reach the component that actually opens the storage connection. CockroachDB 2.1.4 adds an AWS session token to its S3 storage configuration, closing a gap between obtaining temporary credentials and using them in the database's external storage operations.

The 2.1.4 implementation adds AWS_SESSION_TOKEN as an S3 URI query parameter and copies it into the storage configuration's TempToken field. Comparing it with the 2.1.3 implementation shows the specific change. The earlier parser carried the access key and secret but had no session-token parameter.

I like operational costs and dependencies to be explicit. CockroachDB's distributed transaction model makes some costs visible in network round trips. External storage has a separate dependency on authorization, and this change makes one previously missing part of that authorization representable.

The URI carries more than a destination

An S3 URI in this implementation describes a bucket and a prefix, together with authentication parameters. Parsing uses the URI host for the bucket and its path for the prefix. The access key and secret come from named query parameters.

Version 2.1.4 adds the session token alongside those existing fields. It does not remove the checks requiring an access key and a secret. The new parameter is therefore an additional component of the supplied credential, rather than an alternative spelling for the secret.

That distinction matters when constructing a storage URI. A temporary credential cannot be represented correctly by replacing the secret with the session token. The parser expects separate values with separate parameter names, and the storage configuration preserves that distinction.

The change is small in code because it extends an existing abstraction. The shared external-storage interface already supports reading and writing named files under a configured location. Carrying another credential field lets the S3 implementation participate in that interface without requiring every caller to implement its own token handling.

The versioned source also returns a serializable storage configuration through Conf(). This preserves the provider settings as data that can be used to reconstruct the storage implementation. Adding a field to that representation is important when the connection is described in one place and constructed elsewhere.

Storage operations share the same configuration

The S3 implementation uses one configured client for object reads and writes. Its methods also expose deletion and object-size lookup. Those operations work with the configured bucket and combine the prefix with an individual object's name.

This shared implementation explains why token support belongs below a particular SQL command. External-storage callers need a consistent way to describe the same S3 location. Implementing the token only in a command-specific argument parser would leave other callers with a different credential capability.

The source names this interface ExportStorage, but its contract includes reading as well as writing. Its comments describe storage used for purposes such as backups and permit callers to identify either a base location or a single file. Reading remains part of the interface despite its name.

Authentication does not change that file-oriented contract. A credential determines whether the storage service accepts an operation, while the bucket, prefix and filename determine the object involved. Version 2.1.4 adds the missing credential component without changing how object paths are assembled.

My preference is for this kind of shared implementation because it reduces operational surprises between commands. A location that needs a session token should have one representation at the storage boundary. That is more useful than separate, inconsistent conventions for each operation that reads or writes it.

Credential values still need URI encoding

The parser already contains a comment about AWS secrets containing plus characters. In a query string, an unescaped plus can be interpreted as a space. The implementation compensates for that case in the secret field, based on the expected character set of AWS secrets.

That special handling is not a general encoding policy for every credential field. The token is read through the URI query parser into its own field. URI construction still needs to preserve the supplied values correctly, including characters with meaning in query syntax.

This is a useful boundary to keep visible when discussing the feature. Support for a credential format means the application can carry its fields. It does not mean arbitrary string concatenation produces a valid URI for every possible value.

The implementation also provides a sanitizer that removes the query string from a storage URI. Its comment explains that the current providers place credentials there when they carry them in the URI. That sanitization function reflects the sensitivity of the configuration, although its existence alone does not establish that every possible logging path invokes it.

The practical change in 2.1.4 is consequently precise. The S3 parser can retain an access key, a secret and a session token in distinct fields, while the existing storage interface continues to identify and operate on objects. Users supplying temporary AWS credentials gain the representation that the previous release lacked.