Skip to content
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

Merged
merged 8 commits into from
Nov 13, 2023

Conversation

SajanAlexander-okta
Copy link
Contributor

Updates security policies to allow for GA features

  • secrets / secret folders
  • MFA condition
  • constrain security policy for resource group

@@ -43,6 +42,11 @@ func resourceSecurityPolicy() *schema.Resource {
Required: true,
Description: descriptions.SecurityPolicyActive,
},
attributes.ResourceGroup: {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be ResourceGroupID ?

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

Copy link
Contributor

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 ?

Copy link
Contributor Author

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{
Copy link
Contributor

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: {
Copy link
Contributor

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},

Copy link
Contributor Author

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.

},
},
},
},
Copy link
Contributor

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 ?

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

Copy link
Contributor Author

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: {
Copy link
Contributor

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*.

Copy link
Contributor Author

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) {
Copy link
Contributor

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.

oktapam/constants/descriptions/attributes.go Outdated Show resolved Hide resolved
oktapam/constants/descriptions/attributes.go Outdated Show resolved Hide resolved
oktapam/constants/descriptions/attributes.go Outdated Show resolved Hide resolved
oktapam/constants/descriptions/attributes.go Outdated Show resolved Hide resolved
oktapam/constants/descriptions/attributes.go Outdated Show resolved Hide resolved
oktapam/constants/descriptions/attributes.go Outdated Show resolved Hide resolved
oktapam/constants/descriptions/attributes.go Outdated Show resolved Hide resolved
oktapam/constants/descriptions/attributes.go Outdated Show resolved Hide resolved
@@ -69,6 +70,15 @@ Read-Only:
- `traffic_forwarding` (Boolean)


<a id="nestedobjatt--rule--conditions--mfa"></a>
### Nested Schema for `rule.conditions.mfa`

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.

Copy link
Contributor Author

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.

Copy link

@mariovillaplana-okta mariovillaplana-okta left a 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: {

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

},
},
},
},

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

@SajanAlexander-okta SajanAlexander-okta merged commit 6d756e4 into master Nov 13, 2023
6 checks passed
@SajanAlexander-okta SajanAlexander-okta deleted the sajan/security-policy-update branch November 13, 2023 16:10
guoliangye-okta pushed a commit that referenced this pull request Oct 30, 2024
* 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
guoliangye-okta pushed a commit that referenced this pull request Oct 30, 2024
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants