guardian
guardian copied to clipboard
Add custom questions in policy, to be asked when user creates an appeal
Summary While appeal creation the user can be required to answer some questions depending on the policy of a given resource. Currently, the questions asked aren't configurable according to the policy creator. For instance providers like Github/Gitlab will require additional information of userID/username in the appeal which will be required to grant/revoke membership in the organisation.
Requirements
- Configurable questions for appeal creation
- Policy creator should be able to add questions related to access or security, and it can be shown to the approvers for considering their approval. An example question is "What is the purpose of accessing this resource?"
- Provider-specific information that requires to be filled by the appeal creator
- this is more into the required information related to managing access to the provider itself. Like provider account username for granting access (for github)
Proposed solution
There are two approaches to making configurable questions.
- Add questions at the policy level. We will be required to contain questions specific to the provider in the policy which is attached to each resource in the provider config.
-
Pros:
- This option will allow us to ask resource-specific questions from the user since each policy is attached at the resource level in the provider configurations.
-
Cons:
- Redundancy: According to the current use case for the
BigQuery
, suppose we use a single policy (ocean
) with the list of some approvers. And now we want to use the same policy for another provider say,Github
. Assuming the questions being asked in each policy,ocean
will also contain the questionWhat is your Github username
. This will be a redundant question for other providers which use the same policy and doesn't require the Github username (say BigQuery). - There is no provision to check if the policy would contain a particular question will adding that policy to the resource. For example, if we are registering the policy for the Github resource(
organisation
), we can't check that the policy has the question to get theusername
.
- Redundancy: According to the current use case for the
Adding the Questions
field in the policy.go.
type PolicyAppealConfig struct {
DurationOptions []AppealDurationOption
+ Questions []struct{
+ Key string
+ Question string
+ Required bool
+ Description string
+ }
}
This is how the new policy config will look like:
id: bigquery_approval
version: 1
steps: ...
appeal_config:
questions:
- key: "reason"
question: "Why do you need this resource?"
required: true
...
And we are proposing to include the answers in the Options
field in the Appeal struct, instead of creating a new field altogether. Thus no migrations will be required. We will not require to query the database for getting these questions, therefore we can embed the value inside the Options
field.
type AppealOptions struct {
ExpirationDate *time.Time
Duration string
+ Questions []struct{
+ Key string // identifier to the question defined in the policy
+ Value string // answer to the question, which was expected from the user in the appeal
+ }
}
And this is how the final appeal from the user will look like:
{
"account_id": "[email protected]",
"resources": [
{
"id": "e12345ab-4345-4682-8756-88655317e9ea",
"role": "WRITER",
"options":[{
"duration":"48h",
"questions":[{
"key":"foo",
"value": "bar"
}]
}]
}
]
}
- Add questions at the provider level. Whenever a new provider is registered via Guardian the custom question is defined for that during the creation itself.
-
Pros:
- We will be able to configure the questions without any redundancy while using the same policy. We can also keep a check that the provider configurations contain the mandatory questions in the provider config.
-
Cons:
- Questions can only be asked at the provider-level
Note: For this option, the answer to the question will still be in a similar way as discussed in option 1.
The questions
field in this case will be added to the providerConfig.
type ProviderConfig struct {
Type string
URN string
AllowedAccountTypes []string
Labels map[string]string
Credentials interface{}
Appeal *AppealConfig
Resources []*ResourceConfig
+ Parameters []*ProviderParameter
}
+ type ProviderParameter []struct{
+ Key string
+ Label string
+ Required bool
+ Description string
+ }
Note:
- A unique
key
/ID
can be added to easily query the answer of the question later. - We might as well add a field (
regex_validation
)if we want to type check the value entered (say if a userID is expected to only be a number) -
We will also be required to update the CLI and UI on Datlantis to accept answers to custom questions while creating an appeal
@rahmatrhd @ravisuhag @AkarshSatija @mabdh @bsushmith @singhvikash11
How far the customization of questions based on use cases? Will all appeals/policies of a specific provider always have a same question? or Can have custom question for each policy/appeal?
want to help answer @mabdh's question, since the proposed approach right now the questions config lies within the policy, and policy is configured at the resource_type level, so user can customize questions for every resource type in each provider
We can accept the answer to these questions in the appeal details field or add another field altogether for getting the answers to custom questions in the Appeal struct.
@Chief-Rishab can you also give example on how the appeal object looks like with the populated questions and answers within details
and with a new field
@rahmatrhd Does that mean, if we set a custom question for a specific resource type of a provider, all policies created out of it will have the custom questions?
@rahmatrhd do you mean the appeals created for that resource type? yes, during the appeal creation we will fetch the policy attached to the resource and ask the custom questions to the user
Sure @rahmatrhd, I have added the example and relevant details in the proposed solution above
@Chief-Rishab in the Proposed Solution, can you please give more detailed explanation? Another several questions
- How do we store questions and answers in our DB?
- Have we thought about another approach apart from this?
@mabdh I have discussed alternatives with @rahmatrhd and have updated the proposed solution now. We think (Option 2) that is, storing the questions in the provider database is more accurate.
Using Option 1 every provider might not be able to check if the policy is updated with the required questions or not. And the same policy might also be re-used by other providers, and appeal creators will have to answer redundant questions if we add questions to the policy rather than the provider.
For the answers, @rahmatrhd and I both agreed on the same solution mentioned above.