The Access & Provider System is the foundation for Certimate's integration with third-party ecosystems. It decouples identity management (credentials) from operational logic (workflows). This system allows users to store sensitive information like API keys, SSH private keys, or account tokens once and reuse them across multiple certificate issuance and deployment tasks.
The system is split into two primary layers:
The following diagram shows how the frontend UI components and backend domain models interact to manage credentials.
Credential Management Flow
Sources: ui/src/domain/access.ts1-6 internal/domain/access.go7-16 ui/src/domain/provider.ts158-188 internal/domain/provider.go15-139 ui/src/components/access/AccessForm.tsx34-45
An Access record represents a single set of credentials. In the database, these are stored in the access collection defined by CollectionNameAccess. Each record contains a generic Config map that is dynamically unmarshaled into provider-specific Go structs during execution.
| Field | Type | Description |
|---|---|---|
name | string | User-defined label for the credential. |
provider | string | The unique identifier for the service (e.g., aliyun, ssh, volcengine). |
config | map[string]any | JSON object containing keys like accessKeyId, apiToken, etc. |
reserve | string | Internal flag for specialized types (ca or notif). |
Sources: internal/domain/access.go7-16 ui/src/domain/access.ts1-6
Certimate categorizes providers based on their Usage Type (AccessUsageType). A single provider (like Alibaba Cloud, Huawei Cloud, or Volcengine) can support multiple usages.
Provider Usage Mapping
35cn, 51dnscom, beget, gandinet, vultr, akamai_edgedns, ctcccloud_smartdns). ui/src/domain/provider.ts146 internal/domain/provider.go17-133Sources: ui/src/domain/provider.ts145-152 internal/domain/provider.go15-141
The system uses a centralized registry to map provider types to their metadata (icons, display names, and supported features).
accessProvidersMap in ui/src/domain/provider.ts defines the display order and usage capabilities for the UI. ui/src/domain/provider.ts158-188internal/domain/access.go defines the strictly typed Go structures used to parse the JSON configuration of each provider. internal/domain/access.go18-340AccessConfigFieldsProvider component dynamically renders the correct form fields based on the selected provider. ui/src/components/access/AccessForm.tsx49-67AccessConfigForAliyun requires accessKeyId, accessKeySecret, and optional resourceGroupId. internal/domain/access.go68-72AccessConfigForVolcengine requires accessKeyId and secretAccessKey. internal/domain/access.go284-288AccessConfigForSSH requires connection parameters and authentication details. internal/domain/access.go241-252AccessConfigForS3 requires endpoint, region, bucket, and credentials. internal/domain/access.go226-234For details on the full list of providers and their specific fields, see Provider Registry & Access Configuration.
Sources: ui/src/domain/provider.ts158-188 ui/src/components/access/AccessForm.tsx49-67 internal/domain/access.go18-340
The notification system is a specialized implementation of the Provider System. It allows the workflow engine to send status updates (Success/Failure) or expiration warnings through various channels.
The NotifyService utilizes Access records marked with the notification usage to dispatch messages. Supported channels include:
Note: Legacy providers like Bark, Gotify, ServerChan, Pushover, and PushPlus are no longer present in the codebase. Matrix and Mattermost are the current supported self-hosted options.
For details on configuring templates and testing channels, see Notification System.
Sources: ui/src/domain/provider.ts168 internal/domain/provider.go51-134 internal/domain/access.go203-212