From 0607d47b3a0b2b8fdd1dd3be749445ae9e0cd63e Mon Sep 17 00:00:00 2001 From: craig Date: Thu, 27 Jun 2024 14:36:18 +0100 Subject: [PATCH 1/8] rfc for removal of managed zone API --- rfcs/0011-removal-managed-zone.md | 53 +++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 rfcs/0011-removal-managed-zone.md diff --git a/rfcs/0011-removal-managed-zone.md b/rfcs/0011-removal-managed-zone.md new file mode 100644 index 00000000..668f4aaf --- /dev/null +++ b/rfcs/0011-removal-managed-zone.md @@ -0,0 +1,53 @@ +# RFC Template + +- Feature Name: `removal-managed-zone` +- Start Date: 2024-06-26 +- RFC PR: [Kuadrant/architecture#0000](https://github.com/Kuadrant/architecture/pull/0000) +- Issue tracking: [https://github.com/Kuadrant/dns-operator/issues/166](https://github.com/Kuadrant/dns-operator/issues/166) + +# Summary +[summary]: #summary + +Originally the `ManagedZone` API was designed in the context of multiple tenants where the DNS operator was offered as a service and the owner of the service would own the credentials, the dns provider accounts and the zones being worked on. This is no longer the case, however `ManagedZone` has remained in place. It has now become mainly just a reference to a credential to the underlying DNS provider. We do not need this indirection and it provides little to no value to the end user. So we will remove the `ManagedZone API` and replace it with an update to the DNSPolicy and DNSRecord API to add a local reference to a secret containing the needed credentials and any additional configuration. As part of this change we will also bump the version number of the DNSPolicy API to v1alpha2. + +# Motivation +[motivation]: #motivation + +The `ManagedZone` API is required in order to create a DNSPolicy. Its original purpose and value is no longer present. It now creates a barrier and additional learning curve for users. We want to improve this user experience while also simplifying our object model and controller code base. + +The use case here is to avoid having to create additional none policy Kuadrant APIs in order to be able to create an actual policy API. + +# Guide-level explanation +[guide-level-explanation]: #guide-level-explanation + +You will no longer need or be able to create a `ManagedZone` resource. Instead you will create a credential in a Kubernetes secret, but will reference that secret directly from the DNS policy. Any additional provider specific configuration such as the zone ids to work with will be added to the provider credential. + +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +The `ManagedZone` API will be removed. All tests will be updated/removed as needed. We will rename the `managedZoneRef` property to be `providerRef` that will be a required field and will accept the name of a secret in the same namespace. We will expect zone ids to be specified in the provider secret (this is the main piece of configuration in the existing zone resource ). These zone ids will limit what zones the controller will interact with and manage records within. + +# Drawbacks +[drawbacks]: #drawbacks + +We lose the managed zone API which currently allows you to create and delete zones via the resource. We don't see this as really being a bad thing as it is probably to easy to shoot yourself in the foot with this type of API. + +# Rationale and alternatives +[rationale-and-alternatives]: #rationale-and-alternatives + +- This design simplifies the object model, reduces look ups needed and the code base and improves the user experience. + +# Prior art +[prior-art]: #prior-art + +NA + +# Unresolved questions +[unresolved-questions]: #unresolved-questions + +None + +# Future possibilities +[future-possibilities]: #future-possibilities + +We may extend the providerRef property in the future to allow it to use a selector so that you can have multiple provider secrets and have the records populated into multiple providers. \ No newline at end of file From d0e7e010cd2e547ce1dbc618e8d199f999fab313 Mon Sep 17 00:00:00 2001 From: craig Date: Thu, 27 Jun 2024 14:37:22 +0100 Subject: [PATCH 2/8] add pr link --- rfcs/0011-removal-managed-zone.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0011-removal-managed-zone.md b/rfcs/0011-removal-managed-zone.md index 668f4aaf..d69f4a15 100644 --- a/rfcs/0011-removal-managed-zone.md +++ b/rfcs/0011-removal-managed-zone.md @@ -2,7 +2,7 @@ - Feature Name: `removal-managed-zone` - Start Date: 2024-06-26 -- RFC PR: [Kuadrant/architecture#0000](https://github.com/Kuadrant/architecture/pull/0000) +- RFC PR: [https://github.com/Kuadrant/architecture/pull/93](https://github.com/Kuadrant/architecture/pull/93) - Issue tracking: [https://github.com/Kuadrant/dns-operator/issues/166](https://github.com/Kuadrant/dns-operator/issues/166) # Summary From 95a8270777ae3611b5994a27c756f9e56c1d9d4c Mon Sep 17 00:00:00 2001 From: craig Date: Mon, 1 Jul 2024 12:08:06 +0100 Subject: [PATCH 3/8] update managed zone removal RFC --- rfcs/0011-removal-managed-zone.md | 60 ++++++++++++++++++++++++++----- 1 file changed, 52 insertions(+), 8 deletions(-) diff --git a/rfcs/0011-removal-managed-zone.md b/rfcs/0011-removal-managed-zone.md index d69f4a15..7d7e1eb6 100644 --- a/rfcs/0011-removal-managed-zone.md +++ b/rfcs/0011-removal-managed-zone.md @@ -8,24 +8,70 @@ # Summary [summary]: #summary -Originally the `ManagedZone` API was designed in the context of multiple tenants where the DNS operator was offered as a service and the owner of the service would own the credentials, the dns provider accounts and the zones being worked on. This is no longer the case, however `ManagedZone` has remained in place. It has now become mainly just a reference to a credential to the underlying DNS provider. We do not need this indirection and it provides little to no value to the end user. So we will remove the `ManagedZone API` and replace it with an update to the DNSPolicy and DNSRecord API to add a local reference to a secret containing the needed credentials and any additional configuration. As part of this change we will also bump the version number of the DNSPolicy API to v1alpha2. +The `ManagedZone` API was designed in the context of multiple tenants where the DNS operator was offered as a service and the owner of the service would own the credentials, the dns provider accounts and the zones being worked on. It had a requirement of adding and removing zones in the provider dynamically. This is no longer the case, however `ManagedZone` has remained in place. It is mainly a reference to a credential for the underlying cloud DNS provider and a little additional configuration such as the zone id and the root domain in that zone. We do not need this indirection and there is little value to the end user. So we will remove the `ManagedZone API` and replace it with an update to the DNSPolicy and DNSRecord API to add a label selector to secrets containing the needed credentials and the needed additional configuration. As part of this change we will also bump the version number of the DNSPolicy API to v1alpha2. # Motivation [motivation]: #motivation -The `ManagedZone` API is required in order to create a DNSPolicy. Its original purpose and value is no longer present. It now creates a barrier and additional learning curve for users. We want to improve this user experience while also simplifying our object model and controller code base. +The `ManagedZone` API is required in order to create a DNSPolicy. Its original purpose and value is no longer present. It now creates an additional barrier for setting up a `DNSPolicy` that was never intended or really needed once we moved away from offering dns operator as a service. We want to improve this user experience while also simplifying our object model and controller code base. -The use case here is to avoid having to create additional none policy Kuadrant APIs in order to be able to create an actual policy API. +The key user impact here is to avoid users having to create additional none policy `Kuadrant APIs` in order to be able to leverage the `DNSPolicy` API. # Guide-level explanation [guide-level-explanation]: #guide-level-explanation -You will no longer need or be able to create a `ManagedZone` resource. Instead you will create a credential in a Kubernetes secret, but will reference that secret directly from the DNS policy. Any additional provider specific configuration such as the zone ids to work with will be added to the provider credential. +You will no longer need or be able to create a `ManagedZone` resource. It will be expected that the zone already exists in your provider of choice. Now you will only create a credential via a Kubernetes secret. This secret will be where any additional configuration is also applied such as the zone id to target and the root domain in that zone to use. Removing the managed zone API will reduce API calls to the DNS provider and reduce events and load on the server and kuberentes API server. +You will no longer be limited to a single root domain or single provider per policy. The managed zone was a single reference, however we want to move to leverage a label selector which will mean multiple credentials can be used for a single policy. # Reference-level explanation [reference-level-explanation]: #reference-level-explanation -The `ManagedZone` API will be removed. All tests will be updated/removed as needed. We will rename the `managedZoneRef` property to be `providerRef` that will be a required field and will accept the name of a secret in the same namespace. We will expect zone ids to be specified in the provider secret (this is the main piece of configuration in the existing zone resource ). These zone ids will limit what zones the controller will interact with and manage records within. +The `ManagedZone` API will be fully removed. All tests will be updated/removed as needed. We will rename the `managedZoneRef` property to be `providerSelector` that will be a required field and will accept a label selector for secrets within the same namespace as the policy resource. We will expect the zone id and root domain to be specified in the provider secret, these will be required. These zone ids will limit what zones the controller will interact with and manage records within. + +## Secret structure + +under the data field we will expect two new fields to be present + +``` + +ZONE_ID: somezone +DOMAIN_NAME: *.a.b.com + +``` + +If these fields are not present the status of the DNSPolicy will be updated to reflect the issue (more on status below). Only if these fields are present and listeners that match the `DOMAIN_NAME` are present will DNSRecords be created. If no record is created for a given secret, this will be considered a valid configuration (listeners may be added after a secret has been created and we shouldn't assume an error in this case). + + +## Secret label selector + +The reason for using a label selector rather than a direct reference are as follows: + +- It will allow a single DNSPolicy to be applied to multiple dns providers (specific configuration being now present in the secret) +- It will allow for multiple root domains (IE *.b.com and *.a.com can exist on a single gateway) to be used and controlled by DNSPolicy (currently not possible with managed zone) + +Each secret discovered will result in a separate DNSRecord for any targeted listener in the gateway that matches or is a subdomain of the DOMAIN_NAME field specified in the secret using a longest prefix match strategy. Each DNSRecord will have a direct reference to the secret that resulted in its creation. + +## Secret deletion / modification + +When a secret is deleted there will be no action taken by the DNS Controller. When a secret is updated the controller will trigger a reconcile of the policy. + +If the DNS controller fails to access a provider or fails to create the records due to the zone being absent for example, this failure will be reflected in the DNSRecord and piped back to the DNSPolicy status (below). + +## DNSPolicy Status updates + +Each provider secret discovered will have a provider condition in the DNSPolicy reflecting each DNSRecords under the existing `recordConditions` section: + +It will look something like: + +```yaml +Type: ProviderAccessAvailable +Status: True +Message: Access to the dns provider (provider name) is active and available. +Reason: ProviderAccessAvailable +LastTransitionTime: time +``` + +This is also where missing or failed validation of a secrets fields will be reflected. # Drawbacks [drawbacks]: #drawbacks @@ -45,9 +91,7 @@ NA # Unresolved questions [unresolved-questions]: #unresolved-questions -None +There is an unknown in how we want to handle GEO codes. Not all providers use the same codes and so setting a default GEO in the policy could result in unexpected behaviour in the case of multiple secrets targeting multiple providers. # Future possibilities [future-possibilities]: #future-possibilities - -We may extend the providerRef property in the future to allow it to use a selector so that you can have multiple provider secrets and have the records populated into multiple providers. \ No newline at end of file From c35a7ee030beaae6d4ad86138812cdc3f0f263b2 Mon Sep 17 00:00:00 2001 From: craig Date: Mon, 1 Jul 2024 12:13:45 +0100 Subject: [PATCH 4/8] update managed zone removal RFC --- rfcs/0011-removal-managed-zone.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0011-removal-managed-zone.md b/rfcs/0011-removal-managed-zone.md index 7d7e1eb6..a65fcf2a 100644 --- a/rfcs/0011-removal-managed-zone.md +++ b/rfcs/0011-removal-managed-zone.md @@ -8,7 +8,7 @@ # Summary [summary]: #summary -The `ManagedZone` API was designed in the context of multiple tenants where the DNS operator was offered as a service and the owner of the service would own the credentials, the dns provider accounts and the zones being worked on. It had a requirement of adding and removing zones in the provider dynamically. This is no longer the case, however `ManagedZone` has remained in place. It is mainly a reference to a credential for the underlying cloud DNS provider and a little additional configuration such as the zone id and the root domain in that zone. We do not need this indirection and there is little value to the end user. So we will remove the `ManagedZone API` and replace it with an update to the DNSPolicy and DNSRecord API to add a label selector to secrets containing the needed credentials and the needed additional configuration. As part of this change we will also bump the version number of the DNSPolicy API to v1alpha2. +The `ManagedZone` API was designed in the context of multiple tenants where the DNS operator was offered as a service and the owner of the service would own the credentials, the dns provider accounts and the zones being worked on. It had a requirement of adding and removing zones in the provider dynamically. This is no longer the case, but the `ManagedZone` API has remained in place and is mainly a reference to a credential for the underlying cloud DNS provider and some additional configuration such as the zone id and the root domain in that zone. We do not need this indirection and there is little value to the end user. So we will remove the `ManagedZone API` and replace it with an update to the DNSPolicy and DNSRecord API to add a label selector to secrets in the same namespace containing the needed credentials and the needed additional configuration. As part of this change we will also bump the version number of the DNSPolicy API to v1alpha2. # Motivation [motivation]: #motivation From 9f57ae909db2cf718ae0c682c3e36c17ffb19589 Mon Sep 17 00:00:00 2001 From: craig Date: Mon, 1 Jul 2024 12:18:02 +0100 Subject: [PATCH 5/8] update managed zone removal RFC --- rfcs/0011-removal-managed-zone.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0011-removal-managed-zone.md b/rfcs/0011-removal-managed-zone.md index a65fcf2a..379f80e9 100644 --- a/rfcs/0011-removal-managed-zone.md +++ b/rfcs/0011-removal-managed-zone.md @@ -55,7 +55,7 @@ Each secret discovered will result in a separate DNSRecord for any targeted list When a secret is deleted there will be no action taken by the DNS Controller. When a secret is updated the controller will trigger a reconcile of the policy. -If the DNS controller fails to access a provider or fails to create the records due to the zone being absent for example, this failure will be reflected in the DNSRecord and piped back to the DNSPolicy status (below). +If the DNS controller fails to access a provider or fails to create the records due to the secret or specified zone being absent for example, this failure will be reflected in the DNSRecord and piped back to the DNSPolicy status (below). ## DNSPolicy Status updates From 1825789d81c543e2b2d98e5a249b22878b812122 Mon Sep 17 00:00:00 2001 From: craig Date: Tue, 9 Jul 2024 14:39:51 +0100 Subject: [PATCH 6/8] re-focus managed zone removal --- rfcs/0011-removal-managed-zone.md | 72 ++++++++++++++++++------------- 1 file changed, 41 insertions(+), 31 deletions(-) diff --git a/rfcs/0011-removal-managed-zone.md b/rfcs/0011-removal-managed-zone.md index 379f80e9..e4606506 100644 --- a/rfcs/0011-removal-managed-zone.md +++ b/rfcs/0011-removal-managed-zone.md @@ -1,6 +1,6 @@ -# RFC Template +# Remove Managed Zone -- Feature Name: `removal-managed-zone` +- Feature Name: `remove-managed-zone` - Start Date: 2024-06-26 - RFC PR: [https://github.com/Kuadrant/architecture/pull/93](https://github.com/Kuadrant/architecture/pull/93) - Issue tracking: [https://github.com/Kuadrant/dns-operator/issues/166](https://github.com/Kuadrant/dns-operator/issues/166) @@ -8,25 +8,43 @@ # Summary [summary]: #summary -The `ManagedZone` API was designed in the context of multiple tenants where the DNS operator was offered as a service and the owner of the service would own the credentials, the dns provider accounts and the zones being worked on. It had a requirement of adding and removing zones in the provider dynamically. This is no longer the case, but the `ManagedZone` API has remained in place and is mainly a reference to a credential for the underlying cloud DNS provider and some additional configuration such as the zone id and the root domain in that zone. We do not need this indirection and there is little value to the end user. So we will remove the `ManagedZone API` and replace it with an update to the DNSPolicy and DNSRecord API to add a label selector to secrets in the same namespace containing the needed credentials and the needed additional configuration. As part of this change we will also bump the version number of the DNSPolicy API to v1alpha2. +ManagedZone was designed in the context of multiple tenants where the DNS operator was offered as a service and the owner of the service would own the credentials, the dns provider accounts and the zones being worked on. It had a requirement of adding and removing zones in the provider on demand. This is no longer the case, but the `ManagedZone` API has remained in place but is now mainly a reference to a credential for the underlying cloud DNS provider. We do not need this indirection and there is little value to the end user. So lets remove the ManagedZone API and change the DNSPolicy and DNSRecord to a localReference that defaults to a credential secret but is flexible enough to be expanded upon in the future. # Motivation [motivation]: #motivation -The `ManagedZone` API is required in order to create a DNSPolicy. Its original purpose and value is no longer present. It now creates an additional barrier for setting up a `DNSPolicy` that was never intended or really needed once we moved away from offering dns operator as a service. We want to improve this user experience while also simplifying our object model and controller code base. +The motiviation for these changes is to simplify the user experience of setting up a DNSPolicy by removing the need for an existing `ManagedZone` API. As the current reference to the credential is in the ManagedZone API it makes sense to remove that API and move the reference to DNSPolicy. The key user impact here is to avoid users having to create additional none policy `Kuadrant APIs` in order to be able to leverage the `DNSPolicy` API. # Guide-level explanation [guide-level-explanation]: #guide-level-explanation -You will no longer need or be able to create a `ManagedZone` resource. It will be expected that the zone already exists in your provider of choice. Now you will only create a credential via a Kubernetes secret. This secret will be where any additional configuration is also applied such as the zone id to target and the root domain in that zone to use. Removing the managed zone API will reduce API calls to the DNS provider and reduce events and load on the server and kuberentes API server. -You will no longer be limited to a single root domain or single provider per policy. The managed zone was a single reference, however we want to move to leverage a label selector which will mean multiple credentials can be used for a single policy. +There will no longer be a `ManagedZone` resource that needs to be created. It will be expected that the zone already exists in the provider of choice. If it does not exist, you will see this reflected as an error state in the DNSPOlicy status. Credentials will continue to be stored in secrets by default, but these secrets will also be where any additional zone configuration is also applied such as the zone id to target and the root domain in that zone to use. To use different root domains is not currently possible and is outside of the scope of the RFC. # Reference-level explanation [reference-level-explanation]: #reference-level-explanation -The `ManagedZone` API will be fully removed. All tests will be updated/removed as needed. We will rename the `managedZoneRef` property to be `providerSelector` that will be a required field and will accept a label selector for secrets within the same namespace as the policy resource. We will expect the zone id and root domain to be specified in the provider secret, these will be required. These zone ids will limit what zones the controller will interact with and manage records within. +change the DNSPolicy to have local object reference array for provider secrets in the same namespace. + +``` +spec: + providerRefs + - name: myawsroute53 + +``` +Initially this array will have a limit of 1. The reason for an array is we expect to want to allow multiple providers secrets to be specified. This allows us to control the number of secrets and allow for possible expansion in the future. + +Where we use the existing credential we will now load a list of credentials and iterate through each of them and create a specific DNSRecord instance for the target DNS provider populating that DNSRecord with a reference to its required credential. The DNS Operator will pick up on these records in the same way it already does except it will load the secret directly rather than via the ManagedZone. The provider type is already specified as part of our existing secret definition: + +``` +type: kuadrant.io/aws +``` + + All of the tests will be updated/removed as needed. We will rename the `managedZoneRef` property to be `providerRefs` that will be a required field. This will be an array type with the `maxItems` set to 3 initially. + + +Any issues updating a target DNSProvider will be reflected in the existing `recordConditions` status ## Secret structure @@ -39,44 +57,34 @@ DOMAIN_NAME: *.a.b.com ``` -If these fields are not present the status of the DNSPolicy will be updated to reflect the issue (more on status below). Only if these fields are present and listeners that match the `DOMAIN_NAME` are present will DNSRecords be created. If no record is created for a given secret, this will be considered a valid configuration (listeners may be added after a secret has been created and we shouldn't assume an error in this case). - +Validation of the secret structure will happen in the dns operator rather than doing it once in kuadrant and again in the dns operator. If the secret doesn't exist or if the required fields are not present the status of the DNSRecord will be updated to reflect the issue and the DNSPOlicy will reflect this status condition in its existing `recordConditions` section. +DNSPolicy controller will only validate that the specified DOMAIN exists in the target gateway. If it does not exist it will mark this in the status of DNSPolicy. -## Secret label selector -The reason for using a label selector rather than a direct reference are as follows: +## Secret deletion / modification -- It will allow a single DNSPolicy to be applied to multiple dns providers (specific configuration being now present in the secret) -- It will allow for multiple root domains (IE *.b.com and *.a.com can exist on a single gateway) to be used and controlled by DNSPolicy (currently not possible with managed zone) +All secret events will be filtered down to secrets that have: -Each secret discovered will result in a separate DNSRecord for any targeted listener in the gateway that matches or is a subdomain of the DOMAIN_NAME field specified in the secret using a longest prefix match strategy. Each DNSRecord will have a direct reference to the secret that resulted in its creation. +``` +type: kuadrant.io/aws +``` -## Secret deletion / modification +When a secret is deleted the DNSRecord controller will trigger a reconcile of record resources in the same namespace. This will result in a status update on those records that reference this deleted secret that will then be reflected back into the DNSPolicy. Deleting a secret will not result in deleting the associated DNSRecords. +Kuadrant operator does not need to do anything when a secret is deleted as it will be watching the associated DNSRecords and reflecting status back to the DNSPolicy when it changes. -When a secret is deleted there will be no action taken by the DNS Controller. When a secret is updated the controller will trigger a reconcile of the policy. +When a secret is updated or added the DNSRecord controller will trigger a reconcile of records in the same namespace. Kudrant operator will re-validate the domain and continue to watch for status changes to the DNSRecord. -If the DNS controller fails to access a provider or fails to create the records due to the secret or specified zone being absent for example, this failure will be reflected in the DNSRecord and piped back to the DNSPolicy status (below). +If the DNS controller fails to access a provider or fails to create the records due to a bad credential or a specified zone being absent for example, this failure will be reflected in the DNSRecord and piped back to the DNSPolicy. ## DNSPolicy Status updates -Each provider secret discovered will have a provider condition in the DNSPolicy reflecting each DNSRecords under the existing `recordConditions` section: - -It will look something like: +DNSPolicy already reflects the status conditions of each DNSRecords under the existing `recordConditions` section. So no major update is required here. -```yaml -Type: ProviderAccessAvailable -Status: True -Message: Access to the dns provider (provider name) is active and available. -Reason: ProviderAccessAvailable -LastTransitionTime: time -``` - -This is also where missing or failed validation of a secrets fields will be reflected. # Drawbacks [drawbacks]: #drawbacks -We lose the managed zone API which currently allows you to create and delete zones via the resource. We don't see this as really being a bad thing as it is probably to easy to shoot yourself in the foot with this type of API. +We lose a definitive API for modeling a zone. # Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives @@ -91,7 +99,9 @@ NA # Unresolved questions [unresolved-questions]: #unresolved-questions -There is an unknown in how we want to handle GEO codes. Not all providers use the same codes and so setting a default GEO in the policy could result in unexpected behaviour in the case of multiple secrets targeting multiple providers. +None # Future possibilities [future-possibilities]: #future-possibilities + +- Expand the list of credentials to allow populating multiple DNS providers with the record set. From 25c50c6c5c33479776558d46afdbc0ff6d2806fc Mon Sep 17 00:00:00 2001 From: craig Date: Wed, 10 Jul 2024 10:55:50 +0100 Subject: [PATCH 7/8] minor re-rewording --- rfcs/0011-removal-managed-zone.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/rfcs/0011-removal-managed-zone.md b/rfcs/0011-removal-managed-zone.md index e4606506..0f2d5385 100644 --- a/rfcs/0011-removal-managed-zone.md +++ b/rfcs/0011-removal-managed-zone.md @@ -20,7 +20,7 @@ The key user impact here is to avoid users having to create additional none poli # Guide-level explanation [guide-level-explanation]: #guide-level-explanation -There will no longer be a `ManagedZone` resource that needs to be created. It will be expected that the zone already exists in the provider of choice. If it does not exist, you will see this reflected as an error state in the DNSPOlicy status. Credentials will continue to be stored in secrets by default, but these secrets will also be where any additional zone configuration is also applied such as the zone id to target and the root domain in that zone to use. To use different root domains is not currently possible and is outside of the scope of the RFC. +There will no longer be a `ManagedZone` resource that needs to be created as a pre-requisite to setting up a DNSPolicy. Instead it will be expected that the zone already exists in the provider of choice. If it does not exist, you will see this reflected as an error state in the DNSPOlicy status. Credentials will continue to be stored in secrets by default, but these secrets will also be where any additional zone configuration is also applied such as the zone id to target and the root domain in that zone to use. # Reference-level explanation [reference-level-explanation]: #reference-level-explanation @@ -33,18 +33,18 @@ spec: - name: myawsroute53 ``` -Initially this array will have a limit of 1. The reason for an array is we expect to want to allow multiple providers secrets to be specified. This allows us to control the number of secrets and allow for possible expansion in the future. +Initially this array will have a limit of 1. The reason for an object array is we expect to want to allow multiple providers secrets to be specified in the future. This allows us to control the number of secrets and allow for possible expansion in the future. -Where we use the existing credential we will now load a list of credentials and iterate through each of them and create a specific DNSRecord instance for the target DNS provider populating that DNSRecord with a reference to its required credential. The DNS Operator will pick up on these records in the same way it already does except it will load the secret directly rather than via the ManagedZone. The provider type is already specified as part of our existing secret definition: +Where we use the existing credential in the kuadrant operator we will now load a list of credentials and iterate through each of them and create a specific DNSRecord instance for the target DNS provider (again initially only 1) populating that DNSRecord with a reference to its required credential. DNSRecord will only have a single reference. The DNS Operator will pick up on these records in the same way it already does except it will load the secret directly rather than via the ManagedZone. The provider type is already specified as part of our existing secret definition: ``` type: kuadrant.io/aws ``` - All of the tests will be updated/removed as needed. We will rename the `managedZoneRef` property to be `providerRefs` that will be a required field. This will be an array type with the `maxItems` set to 3 initially. + All of the tests will be updated/removed as needed. We will rename the `managedZoneRef` property to be `providerRefs` that will be a required field. This will be an array type with the `maxItems` set to 1 initially. -Any issues updating a target DNSProvider will be reflected in the existing `recordConditions` status +Any issues updating/contacting a target DNS provider will be reflected in the existing `recordConditions` status via the existing `synchronised` condition. ## Secret structure @@ -57,7 +57,7 @@ DOMAIN_NAME: *.a.b.com ``` -Validation of the secret structure will happen in the dns operator rather than doing it once in kuadrant and again in the dns operator. If the secret doesn't exist or if the required fields are not present the status of the DNSRecord will be updated to reflect the issue and the DNSPOlicy will reflect this status condition in its existing `recordConditions` section. +Validation of the secret structure will happen in the dns operator rather than doing it once in the kuadrant operator and again in the dns operator. If the secret doesn't exist or if the required fields are not present the status of the DNSRecord will be updated to reflect the issue and the DNSPOlicy will reflect this status condition in its existing `recordConditions` section as it does now. DNSPolicy controller will only validate that the specified DOMAIN exists in the target gateway. If it does not exist it will mark this in the status of DNSPolicy. @@ -69,12 +69,12 @@ All secret events will be filtered down to secrets that have: type: kuadrant.io/aws ``` -When a secret is deleted the DNSRecord controller will trigger a reconcile of record resources in the same namespace. This will result in a status update on those records that reference this deleted secret that will then be reflected back into the DNSPolicy. Deleting a secret will not result in deleting the associated DNSRecords. -Kuadrant operator does not need to do anything when a secret is deleted as it will be watching the associated DNSRecords and reflecting status back to the DNSPolicy when it changes. +When a secret is deleted the DNSRecord controller will trigger a reconcile of record resources in the same namespace. This will result in a status update on those records that reference this deleted secret informing of a missing secret, this will then automatically be reflected back into the DNSPolicy. Deleting a secret will not result in deleting the associated DNSRecords. +Kuadrant operator does not need to do anything when a secret is deleted as it will be watching the associated DNSRecords and reflecting status back to the DNSPolicy when it changes. Kuadrant operators responsibility it to ensure a correct DNSRecord is constructed and then pipe that through to the DNSOperator. It does not interact with the DNSProvider. -When a secret is updated or added the DNSRecord controller will trigger a reconcile of records in the same namespace. Kudrant operator will re-validate the domain and continue to watch for status changes to the DNSRecord. +When a secret is updated or added the DNSRecord controller will trigger a reconcile of records in the same namespace. Kudrant operator will re-validate the domain and continue to watch for status changes to the DNSRecords. -If the DNS controller fails to access a provider or fails to create the records due to a bad credential or a specified zone being absent for example, this failure will be reflected in the DNSRecord and piped back to the DNSPolicy. +If the DNSRecord controller fails to access a provider or fails to create the records due to a bad credential or a specified zone being absent for example, this failure will be reflected in the DNSRecord and piped back to the DNSPolicy. ## DNSPolicy Status updates From 5915970c69682f67e6f16e876385c452eede2025 Mon Sep 17 00:00:00 2001 From: Michael Nairn Date: Mon, 12 Aug 2024 11:04:21 +0100 Subject: [PATCH 8/8] Update to include zone filter fields in provider secrets Signed-off-by: Michael Nairn --- rfcs/0011-removal-managed-zone.md | 34 +++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-) diff --git a/rfcs/0011-removal-managed-zone.md b/rfcs/0011-removal-managed-zone.md index 0f2d5385..c0a5f58c 100644 --- a/rfcs/0011-removal-managed-zone.md +++ b/rfcs/0011-removal-managed-zone.md @@ -20,7 +20,7 @@ The key user impact here is to avoid users having to create additional none poli # Guide-level explanation [guide-level-explanation]: #guide-level-explanation -There will no longer be a `ManagedZone` resource that needs to be created as a pre-requisite to setting up a DNSPolicy. Instead it will be expected that the zone already exists in the provider of choice. If it does not exist, you will see this reflected as an error state in the DNSPOlicy status. Credentials will continue to be stored in secrets by default, but these secrets will also be where any additional zone configuration is also applied such as the zone id to target and the root domain in that zone to use. +There will no longer be a `ManagedZone` resource that needs to be created as a pre-requisite to setting up a DNSPolicy. Instead it will be expected that a zone already exists in the provider of choice. If a suitable zone does not exist, you will see this reflected as an error state in the DNSPolicy status. Credentials will continue to be stored in secrets by default, but these secrets will also be where any additional zone configuration is also applied such as the zone id to target and the root domain in that zone to use. # Reference-level explanation [reference-level-explanation]: #reference-level-explanation @@ -41,25 +41,43 @@ Where we use the existing credential in the kuadrant operator we will now load a type: kuadrant.io/aws ``` - All of the tests will be updated/removed as needed. We will rename the `managedZoneRef` property to be `providerRefs` that will be a required field. This will be an array type with the `maxItems` set to 1 initially. - +All the tests will be updated/removed as needed. We will rename the `managedZoneRef` property to be `providerRefs` that will be a required field. This will be an array type with the `maxItems` set to 1 initially. Any issues updating/contacting a target DNS provider will be reflected in the existing `recordConditions` status via the existing `synchronised` condition. ## Secret structure -under the data field we will expect two new fields to be present +Under the data field two new optional filter fields can be added ``` - -ZONE_ID: somezone -DOMAIN_NAME: *.a.b.com - +ZONE_ID_FILTER: somezone +DOMAIN_NAME_FILTER: a.b.com ``` Validation of the secret structure will happen in the dns operator rather than doing it once in the kuadrant operator and again in the dns operator. If the secret doesn't exist or if the required fields are not present the status of the DNSRecord will be updated to reflect the issue and the DNSPOlicy will reflect this status condition in its existing `recordConditions` section as it does now. DNSPolicy controller will only validate that the specified DOMAIN exists in the target gateway. If it does not exist it will mark this in the status of DNSPolicy. +Note: Adding no filters means that the provider will consider all zones that you supplied provider credentials have access to. + +Example: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: myawsroute53 +type: kuadrant.io/aws +stringData: + ZONE_DOMAIN_FILTER: "example.com,foo.example.com" + ZONE_ID_FILTER: "/hostedzone/12345abcd,/hostedzone/dcba54321" +``` + +### ZONE_ID_FILTER + +The zone id filter allows a comma seperated list of zone ids to be added to the secret that will scope the zones that can be assigned to DNSRecords and have records published into. + +### ZONE_DOMAIN_FILTER + +The zone domain filter allows a comma seperated list of zone dns names to be added to the secret that will scope the zones that can be assigned to DNSRecords and have records published into. ## Secret deletion / modification