Potential Policy workflow for Synchronizer leader election #2543
Conversation
| body: | ||
| - !variable leader-expiration | ||
|
|
||
| # The Group all Synchronizer hosts need to be added to. |
There was a problem hiding this comment.
How can I do that?
I see a few use cases here
- First installation
- Synchronizer installer creates this policy
- Synchronizer installer creates another policy for safes, lobs etc altogether with Synchronizer host
- Synchronizer installer needs to update this policy - with host how?
- Installation of second instance of Synchronizer
- Synchronizer installer updates another policy for safes, lobs etc altogether with new Synchronizer host
- Synchronizer installer needs to update this policy - with host how?
- A few Synchronizer installers already exists - manual update needed
- This policy is created manually
- How to add already existing hosts here
- Synchronizer uninstall
- How to remove host from this group
There was a problem hiding this comment.
@GrzegorzK-CA, I put together a working example in the Conjur Intro project: https://github.com/conjurdemos/conjur-intro/blob/vault-synchronizer/bin/dap#L428.
The only thing missing here is setting the JSON document with safe names and last updated dates. Bash does not like the double quotes of JSON. Because the JSON is passed through so many functions, I was not able to get it escaped correctly. I updated the variable via the UI to make sure it worked as expected. You should have no problem doing this with the .NET SDK.
|
|
||
| Then compare returned Unix epoch time time to current Unix epoch time. | ||
|
|
||
| 1. Delete leader host: |
There was a problem hiding this comment.
What happens in the very first flow:
- no leader
- trying to delete vault-synchronizer-leader if that doesn't exist?
Should I check if that variable is set altogether with expiration date or can I just try to delete it and then try to create it.
There was a problem hiding this comment.
Delete on a resource that's not present results in a no-op, so it should be fine to always attempt the delete before trying to claim "leader" status.
| 1. Update `leader-expiration` to future time: | ||
|
|
||
| ```sh | ||
| POST /secrets/{account}/variable/conjur%2Fvault-synchronizer%2Fleader-expiration |
There was a problem hiding this comment.
"secrets"?
I thought it would be something like "conjur/vault-synchronizer/...."
but I guess this might be my lack of knowledge here
how about creating/updating variables for LOBs - will that also be under "secrets"?
There was a problem hiding this comment.
In this case secrets is the resource type. conjur%2Fvault-synchronizer%2Fleader-expiration is the url escaped variable ID.
| - !policy | ||
| id: vault-lines-of-business | ||
| owner: !group members | ||
| body: |
There was a problem hiding this comment.
I guess this "vault-lines-of-business" policy should be created without body, and Synchronizer should create variables for each LOBs during synchonization intervals.
It would be great to have examples for that as well
There was a problem hiding this comment.
Great catch. I updated this in the Conjur Intro example above.
conjur-jenkins
force-pushed
the
master
branch
2 times, most recently
from
6566647 to
d65d499
Compare
conjur-jenkins
force-pushed
the
master
branch
from
d65d499 to
dbea020
Compare
conjur-jenkins
force-pushed
the
master
branch
from
dbea020 to
8031a2a
Compare
2 participants
Desired Outcome
Please describe the desired outcome for this PR. Said another way, what was
the original request that resulted in these code changes? Feel free to copy
this information from the connected issue.
Implemented Changes
Describe how the desired outcome above has been achieved with this PR. In
particular, consider:
Connected Issue/Story
Resolves #[relevant GitHub issue(s), e.g. 76]
CyberArk internal issue link: insert issue ID
Definition of Done
At least 1 todo must be completed in the sections below for the PR to be
merged.
Changelog
CHANGELOG update
Test coverage
changes, or
Documentation
READMEs) were updated in this PRBehavior
Security