Documentation
¶
Overview ¶
Package azure implements the create-only Destination for Azure Blob Storage. WORM is a time-based retention policy on the container that has been locked; writes are create-only via If-None-Match. Auth uses DefaultAzureCredential. There is no delete path.
Index ¶
- type Backend
- func (b *Backend) Get(ctx context.Context, key string) (io.ReadCloser, error)
- func (b *Backend) List(ctx context.Context, prefix string) ([]dest.Object, error)
- func (b *Backend) ListPage(ctx context.Context, prefix string, limit int) ([]dest.Object, bool, error)
- func (b *Backend) ObserveRetention(ctx context.Context, key string) (dest.RetentionObservation, time.Time, error)
- func (b *Backend) PutImmutable(ctx context.Context, key string, r io.Reader, size int64, _ dest.Retention) (dest.PutResult, error)
- func (b *Backend) VerifyWorm(ctx context.Context) (dest.WormStatus, error)
- type Options
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Backend ¶
type Backend struct {
// contains filtered or unexported fields
}
Backend is a create-only Azure Blob Destination.
func (*Backend) ListPage ¶ added in v0.1.21
func (b *Backend) ListPage(ctx context.Context, prefix string, limit int) ([]dest.Object, bool, error)
ListPage lists at most limit blobs under prefix with one List Blobs request (read-only), and says whether the store reported more. Azure may answer a page with fewer blobs than asked for, none included, and a continuation; that continuation is never followed here.
func (*Backend) ObserveRetention ¶ added in v0.1.16
func (b *Backend) ObserveRetention(ctx context.Context, key string) (dest.RetentionObservation, time.Time, error)
ObserveRetention asks Blob Storage what immutability is actually on an object gitdr wrote.
Azure's model is container-level rather than per-object: `PutImmutable` sends no retention and records none, so unlike S3 there is no per-object date in the manifest to be wrong. What can still be wrong is the same shape one level up: a container that reports a locked policy while blobs come back without one is the identical unearned claim.
`x-ms-immutability-policy-until-date` is returned only when a policy is set on the blob, and a policy can be set on a blob only in a container with version-level immutability. There, a blob without one is the earned negative: the container's default was not applied to this write. In a container protected by a container-level policy the blob never carries the header, however locked the container is, so its absence says nothing and is reported as not checked. Reading that absence as "nothing holds this object" is exactly the false negative this type exists to prevent. A failed read says nothing either.
func (*Backend) PutImmutable ¶
func (b *Backend) PutImmutable(ctx context.Context, key string, r io.Reader, size int64, _ dest.Retention) (dest.PutResult, error)
PutImmutable uploads key create-only (If-None-Match: *); immutability is enforced by the container's immutability policy. Never overwrites, never deletes.
The blocks are sized from size, so that no blob needs more of them than Azure commits. Up to v0.1.20 every blob went in the SDK's 1 MiB blocks, and one over 48.8 GiB, 50,000 of them, failed at Put Block List, after all of it had been sent.
The size recorded is what was read from r and committed, and it has to be size: a stream that ran short or long is not the artifact that was checksummed. Up to v0.1.20 it recorded 0 for every blob.
func (*Backend) VerifyWorm ¶
VerifyWorm says immutable only for a container whose time-based retention policy Resource Manager reports as Locked.
It used to say immutable whenever the container had version-level immutability enabled. That flag says blob versions can carry policies, not that any does: a container with the flag and no policy protects nothing, and an unlocked policy can be shortened or deleted by the account owner, the identity an attacker is most likely to hold. The blob endpoint cannot tell any of that from a locked policy. It reports that a policy exists (x-ms-has-immutability-policy) and never its state or its period, so without the Resource Manager read the honest answer is unknown.
immutable Resource Manager reported the container's policy Locked, with its period
not-immutable the store answered and nothing here is locked: no policy and no version-level
immutability, or a policy that is Unlocked
unknown a policy or version-level immutability exists and its lock was not read, or
Resource Manager refused the question
type Options ¶
type Options struct {
Account string // storage account (real Azure)
Container string
Endpoint string // override service URL; default https://<account>.blob.core.windows.net/
ConnectionString string // for Azurite or shared-key auth
// SubscriptionID and ResourceGroup locate the storage account in Azure Resource Manager.
//
// Optional, and without them the WORM check never says immutable. Whether a container's
// immutability policy is locked is reported only by Resource Manager: the blob endpoint says
// a policy exists and nothing about whether it can still be shortened or deleted. The read
// uses DefaultAzureCredential even when a connection string is set, because an account key
// does not authenticate to Resource Manager.
SubscriptionID string
ResourceGroup string
}
Options configures the Azure Blob backend. Credentials come from DefaultAzureCredential (real Azure) or a connection string (emulator / shared key).
Source Files