-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OKTA-649266 - update security policy for GA features #115
Conversation
52cec8a
to
f40096e
Compare
f40096e
to
70de240
Compare
@@ -43,6 +42,11 @@ func resourceSecurityPolicy() *schema.Resource { | |||
Required: true, | |||
Description: descriptions.SecurityPolicyActive, | |||
}, | |||
attributes.ResourceGroup: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be ResourceGroupID ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I think it's a named object so this should work fine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mariovillaplana-okta I didn't get it. We pass ResourceGroupID for this attribute, correct ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I've seen, we generally use the term without the ID
as attribute names, but have the description indicate that the expectation is the UUID
MaxItems: 1, | ||
Description: descriptions.SecurityPolicySecrets, | ||
Elem: &schema.Resource{ | ||
Schema: map[string]*schema.Schema{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's fine to add all the schema in the parent SecurityPolicy schema, but for readability I like creating separate schema type and then referencing it.
Description: descriptions.SecurityPolicySecrets, | ||
Elem: &schema.Resource{ | ||
Schema: map[string]*schema.Schema{ | ||
attributes.Secret: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think only Secret or SecretFolder can be specified but not both. You can use ConflictsWith property in the schema. Take a look at -
ConflictsWith: []string{certDetailsTTLDays}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we use TypeLists/TypeSets, using ConflictsWith is kind of a nightmare. I ended up doing the validation within the code itself.
}, | ||
}, | ||
}, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can policy have multiple secret folders ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A policy, yes, but not in a single rule
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've constrained this.
Description: descriptions.PrivilegeSecret, | ||
Elem: &schema.Resource{ | ||
Schema: map[string]*schema.Schema{ | ||
attributes.List: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why these privileges need to be required ? Also, there are different privileges for secret and folder. If in the policy, we have a SecretFolder resource then what is the relevance of PrivilegeSecret*.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My goal here is to be explicit on the privileges granted, even if the default is false.
There are not different privileges for a secret/folder.
policy := client.SecurityPolicy{ | ||
ID: id, | ||
Name: GetStringPtrFromResource(attributes.Name, d, false), | ||
Active: GetBoolPtrFromResource(attributes.Active, d, false), | ||
Description: GetStringPtrFromResource(attributes.Description, d, false), | ||
} | ||
|
||
if resourceGroupID := GetStringPtrFromResource(attributes.ResourceGroup, d, false); resourceGroupID != nil { | ||
if MatchesUUID(*resourceGroupID) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think UUID check can be part of the schema validation.
@@ -69,6 +70,15 @@ Read-Only: | |||
- `traffic_forwarding` (Boolean) | |||
|
|||
|
|||
<a id="nestedobjatt--rule--conditions--mfa"></a> | |||
### Nested Schema for `rule.conditions.mfa` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's hard for me to tell - does this allow them to try to set up MFA conditions on secret rules? That's not currently supported. I suppose the same question would apply to gateway conditions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We constrain gateways, but not MFA - the main reason is that while this is not currently supported, we don't want to have to roll another version of the TF provider and migrate people when support is added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving since the API will surface the error if they try to add an MFA condition to a secret rule, but just wondering about the current behavior. Please test locally before merging
@@ -43,6 +42,11 @@ func resourceSecurityPolicy() *schema.Resource { | |||
Required: true, | |||
Description: descriptions.SecurityPolicyActive, | |||
}, | |||
attributes.ResourceGroup: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I think it's a named object so this should work fine
}, | ||
}, | ||
}, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A policy, yes, but not in a single rule
Co-authored-by: isaacdurham-okta <89145748+isaacdurham-okta@users.noreply.github.com>
* OKTA-649266 - update security policy for GA features * fix test * doc update * sort incoming list * Doc updates Co-authored-by: isaacdurham-okta <89145748+isaacdurham-okta@users.noreply.github.com> * constrain conditions * doc generation * constrain to one secret or secret folder in rule --------- Co-authored-by: isaacdurham-okta <89145748+isaacdurham-okta@users.noreply.github.com> initial commit
* OKTA-649266 - update security policy for GA features * fix test * doc update * sort incoming list * Doc updates Co-authored-by: isaacdurham-okta <89145748+isaacdurham-okta@users.noreply.github.com> * constrain conditions * doc generation * constrain to one secret or secret folder in rule --------- Co-authored-by: isaacdurham-okta <89145748+isaacdurham-okta@users.noreply.github.com> initial commit
Updates security policies to allow for GA features