Access Policies
Create reusable project policies that control when, where, and how machines read secrets, including lifecycle and rotation triggers.
Access policies are reusable, project-level sets of conditions that SikkerKey evaluates when a machine reads a bound secret. A policy can limit reads by time, network, request frequency, or a second machine’s recent activity, and it can control when a secret is destroyed or rotated.
Create a policy once, bind it to one or more secrets in the same project, and manage the shared rule from the project’s Policies page. Every enabled condition must pass before SikkerKey returns a value.
Policy changes take effect on the next request. Editing one policy updates the read conditions for every secret currently bound to it.
#How access policies work
Create a named policy inside a project.
Enable the read conditions and lifecycle controls you need.
Bind the policy to secrets from the project’s Secrets page.
A machine authenticates, reaches the project, and presents its secret grant.
SikkerKey evaluates the bound policy before decrypting or issuing the secret.
An allowed read succeeds and updates the policy’s counters. A blocked read is recorded in the Audit Log with the reason.
One policy can protect many secrets. Each secret can be bound to one policy at a time, and every binding stays within its project.
#Open the Policies page
Select a project, then choose Policies in the project navigation. The Access Policies table shows:
Name and description.
A colored tag for each active condition or lifecycle control.
The number of secrets currently bound to the policy.
The most recent update date.
Configure and Delete actions when you have policy management permission.
Use the search field to find a policy by name, description, or policy ID.
#Create a policy
Open the project’s Policies page.
Select the plus button.
Enter a policy name and an optional description.
Enable and configure the conditions you want SikkerKey to enforce.
Add lifecycle controls where required.
Review the active-condition tags at the bottom of the editor.
Select Create policy.
A policy name can contain up to 255 characters and must be unique within its project. Use names that describe the protected workload or rule, such as prod-database-window, office-network-only, or release-credentials.
#Configure read conditions
The Constraints section contains four independently configurable checks. When several are enabled, a request must satisfy all of them.
Time window
Time window restricts successful reads to selected days and hours in a chosen timezone.
Setting | How it is evaluated |
|---|---|
Start and end | Inclusive local times in 24-hour HH:mm format. |
Timezone | An IANA timezone such as Europe/Copenhagen or America/New_York. |
Days | One or more selected weekdays from Monday through Sunday. |
Overnight window | A start later than the end, such as 22:00 to 06:00, spans midnight. |
For an overnight window, select every local calendar day on which reads should be accepted. For example, a Monday-night window that continues into Tuesday morning requires both Monday and Tuesday when the early-morning portion should remain available.
The timezone setting follows local clock changes, including daylight-saving transitions. Reads outside the configured window are blocked.
IP allowlist
IP allowlist permits reads when the source IP address observed by SikkerKey matches at least one configured address or CIDR range.
Enter one address or range per line.
IPv4 and IPv6 are supported.
A single address is accepted without a prefix.
Network ranges use CIDR notation, such as 10.0.0.0/8 or 2001:db8::/32.
Entries are normalized and duplicates are removed when the policy is saved.
Use the egress addresses of the workload or network that will make the machine request. Reads from other source addresses are blocked before the secret is decrypted.
Read-rate cap
Read-rate cap limits successful reads of each bound secret. Configure a daily limit, a per-minute limit, or both.
Limit | Counter scope |
|---|---|
Max per day | Successful reads of one secret during the current UTC calendar day. |
Max per minute | Successful reads of one secret during the current one-minute bucket. |
Counters are maintained separately for every secret. If three secrets share the same policy, each receives the complete configured allowance. When a counter reaches its cap, further reads in that bucket receive a rate-limited response.
Current counters follow the secret across policy edits and rebindings during the same time bucket. Blocked attempts do not consume the read allowance.
Co-sign
Co-sign requires a recent successful read of the same secret by a selected machine in the same project before another machine can read it.
Setting | Purpose |
|---|---|
Co-signer machine | The machine whose successful read provides the qualifying event. |
Window | How long that successful read remains valid, from 1 second to 86,400 seconds. |
The machine requesting the gated read must be different from the selected co-signer. SikkerKey looks for a successful read by the co-signer within the configured window; without one, the request is blocked.
Choose a co-signer that participates in the operational sequence you want to protect, and set a window long enough for the qualifying read and the dependent workload request to complete.
#Configure lifecycle controls
The Lifecycle section can retire a secret at a fixed time, retire it after a total number of reads, or trigger rotation after reads of the current version.
Destroy at
Destroy at sets a fixed date and time. At that moment, machine reads are blocked immediately. A scheduled cleanup moves every live secret bound to the expired policy into Trash, normally within five minutes, and records a critical Secret destroyed event.
The timestamp belongs to the policy, so every bound secret shares it. Editing the timestamp before it expires updates the lifecycle for the entire bound set.
Destroy after N reads
Destroy after N reads gives each bound secret its own lifetime disclosure budget. The read that reaches N succeeds and returns the value; SikkerKey then moves that secret into Trash. Later reads receive a gone response.
The budget uses the secret’s accumulated policy-tracked successful-read count. Changing or replacing the policy binding does not reset that total.
Treat this value as a destructive threshold. Test the expected read pattern on a non-production secret before applying it to active credentials.
Rotate after N reads
Rotate after N reads requests a rotation when the current secret version reaches the configured number of successful reads. The threshold-crossing read succeeds, the rotation follows, and the version counter resets when the new value is promoted.
A secret must already have a rotation schedule or a managed-secret configuration before it can be bound to a policy with this control. SikkerKey validates that requirement during binding.
#Bind a secret to a policy
Open the project’s Secrets page.
Find the secret in the main secrets table.
Open the Policy dropdown in that row.
Select a policy from the same project.
Wait for the table to refresh and confirm the policy name.
Selecting a different policy replaces the current binding. Select None (unbind) to detach the policy from that secret.
Bind several secrets
Select the secrets in the table.
Open Bind to policy in the bulk-action toolbar.
Choose the policy or None (unbind).
Select Apply and confirm the operation.
Bulk binding applies the change to each selected secret. Any secret that cannot accept the selected policy is reported as a failed item while successful bindings remain applied.
Review bound secrets from the policy
Open Configure on an existing policy to view its Bound secrets section. The section lists each secret by name and ID. You can detach an individual secret or use Detach all to clear the complete binding list.
#How policies affect machine requests
Policy evaluation occurs after machine authentication, project membership, the project’s active state, and the explicit secret grant have succeeded. It occurs before SikkerKey returns the value.
Result | Machine-facing behavior |
|---|---|
Time, IP, or co-sign condition fails | The request is forbidden. |
Read-rate limit is reached | The request is rate limited. |
Destroy-at time or read budget is exhausted | The secret is reported as gone. |
Every enabled condition passes | The secret is returned and successful-read counters advance. |
A bound secret is blocked during bulk export | That secret is omitted while other eligible secrets remain in the export. |
For canary secrets, the canary response runs only after the policy permits the read. For leased secrets, the applicable pre-issuance conditions are evaluated before credentials are issued.
#Evaluation order
SikkerKey stops at the first failed check and records that reason. Conditions are evaluated in this order:
Fixed destroy-at timestamp.
Total-read destruction budget.
Time window.
IP allowlist.
Daily and per-minute read-rate caps.
Co-sign requirement.
This order determines the reason shown in the Audit Log when more than one condition would block the same request.
#Edit a policy
Open the project’s Policies page.
Open the policy’s action menu and select Configure.
Update its name, description, conditions, or lifecycle controls.
Review the active-condition tags.
Select Save changes.
The new configuration applies to all bound secrets on their next request. Create a separate policy and rebind a subset of secrets when they need a different rule set.
#Delete a policy
A policy must have zero bound secrets before deletion. The Bound column and the Bound secrets section show what must be detached.
Configure the policy and detach its bound secrets.
Return to the Access Policies table.
Open the action menu and select Delete.
Confirm the deletion.
The deletion is immediate and recorded in the Audit Log.
#Operational guidance
Start with one clearly named policy for one workload or security boundary.
Bind a test secret and confirm both allowed and blocked reads before applying the policy broadly.
Use the exact egress IP addresses observed for the workload.
Select the correct local timezone and every required day for overnight windows.
Size rate caps from measured normal traffic and expected deployment bursts.
Treat destroy-at and destroy-after-read changes as credential retirement actions.
Keep rotation infrastructure healthy before enabling rotate-after-read triggers.
Review High blocked-read events for unexpected machines, networks, or request times.
#Troubleshooting
A machine receives a forbidden response
Open the Audit Log and find the High Secret read blocked event. Its detail identifies whether the time window, IP allowlist, or co-sign requirement failed. Confirm the machine’s request time, observed source IP address, and recent co-signer activity.
A machine receives a rate-limited response
Review the policy’s per-minute and per-day limits and the workload’s read pattern. Wait for the relevant bucket to reset or raise the limit to a measured safe value.
A secret is reported as gone
Check the policy’s Destroy at and Destroy after N reads settings, then review Secret destroyed events and Trash. Restore or replace the credential according to your recovery procedure before changing the lifecycle policy.
A policy cannot be bound
Confirm the policy and secret belong to the same project. When Rotate after N reads is configured, confirm the secret has a rotation schedule or an active managed-secret configuration.
A policy cannot be deleted
Check the Bound count, open Configure, and detach every listed secret. Delete becomes available when the count reaches zero.
An overnight time window blocks early-morning reads
Select the weekday that contains the early-morning portion as well as the weekday on which the window starts.