You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support invalidating passwords and regenerating them on a regular cadence similar to application_password
Use cases
Some requirements you'd encounter in most security-aware organizations:
Company policy requires passwords of "privileged" users/systems/accounts to be changed regularly.
Shared accounts are required to have their passwords changed whenever someone with access to it leaves or their account is suspended (for example, a precaution their laptop/phone got stolen)
Emergency (break the glass) accounts must have their password "rotated" at a regular cadence.
Proposed solution
One option would be to introduce a new resource, onepassword_item_password. This allows the password to have a distinct lifecycle from the item. Note rotate_when_changed. This method will enable us to use anything to trigger a password regeneration.
Another option would be to have a data block to generate a password like this:
resource "time_rotating" "example" {
rotation_days = 1
}
# trying to be as close to the random_password provided by Hashicorp
data "onepassword_password" "example" {
length = 48
special = true
rotate_when_changed = {
rotation = time_rotating.example.id
}
}
resource "onepassword_item" "example" {
title = "Example"
username = "bob"
password = data.onepassword_password.example.value
}
resource "dummy_user" "example" {
hostname = "dummy.example.net"
username = "dummy"
password = onepassword_item.example.password
}
A third would be to have rotate_when_changed on the onepassword_item resource, but this would complicate matters whenever there is more than one password in the resource.
A fourth option would be to add rotate_when_changed to the password recipe.
Is there a workaround to accomplish this today?
Resort to writing your code or scripts; call it from Terraform, which is less than ideal.
References & Prior Work
The best example of this behavior would be the application_password
of Azure Active Directory.
The text was updated successfully, but these errors were encountered:
Just replace the password resource when the time rotation resource updates, and use that value in the password. It'd be nice to use 1password's password generation logic, of course, but this generally works for me. :)
Summary
Support invalidating passwords and regenerating them on a regular cadence similar to application_password
Use cases
Some requirements you'd encounter in most security-aware organizations:
Proposed solution
One option would be to introduce a new resource,
onepassword_item_password.
This allows the password to have a distinct lifecycle from the item. Noterotate_when_changed
. This method will enable us to use anything to trigger a password regeneration.Another option would be to have a data block to generate a password like this:
A third would be to have
rotate_when_changed
on theonepassword_item
resource, but this would complicate matters whenever there is more than one password in the resource.A fourth option would be to add
rotate_when_changed
to the password recipe.Is there a workaround to accomplish this today?
Resort to writing your code or scripts; call it from Terraform, which is less than ideal.
References & Prior Work
The best example of this behavior would be the application_password
of Azure Active Directory.
The text was updated successfully, but these errors were encountered: