From 97116c82be4c48a0592529e4aa50d68a24aa6744 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Natalie=20Klestrup=20R=C3=B6ijezon?= Date: Tue, 14 Jan 2025 13:14:01 +0100 Subject: [PATCH 1/3] Document required AD ACLs --- .../secret-operator/pages/secretclass.adoc | 44 +++++++++++++++++-- 1 file changed, 41 insertions(+), 3 deletions(-) diff --git a/docs/modules/secret-operator/pages/secretclass.adoc b/docs/modules/secret-operator/pages/secretclass.adoc index 9e716369..1ffbfd56 100644 --- a/docs/modules/secret-operator/pages/secretclass.adoc +++ b/docs/modules/secret-operator/pages/secretclass.adoc @@ -219,6 +219,44 @@ If the same AD domain _is_ shared between multiple Kubernetes clusters, the foll * The Kubernetes Nodes' names and fully qualified domain names * The Kubernetes Namespaces' names (only Namespaces that use Kerberos) +[#ad-acl] +===== Access Control + +The Secret Operator needs permission to create users in the configured base container +(`kerberosKeytab.admin.activeDirectory.userDistinguishedName`), as well as to reset their passwords. + +This can be configured using the following PowerShell script: + +// FIXME: This script is copied from ad-init, can we share this somehow? + +[source,powershell] +---- +Import-Module ActiveDirectory +# Change these variables to fit your environment +$ou_path = "AD:OU=SDP,DC=sble,DC=test" +$secretop = [System.Security.Principal.SecurityIdentifier]::New("S-1-5-21-1256652973-2063416196-3566311115-1103") + +$acl = Get-ACL -Path $ou_path +$user_schema_guid = "bf967aba-0de6-11d0-a285-00aa003049e2" +$password_reset_right_guid = "00299570-246d-11d0-a768-00aa006e0529" +$ou_create_children_rule = [System.DirectoryServices.ActiveDirectoryAccessRule]::New( + $secretop, + [System.DirectoryServices.ActiveDirectoryRights]::CreateChild, + [System.Security.AccessControl.AccessControlType]::Allow, + $user_schema_guid, + [System.DirectoryServices.ActiveDirectorySecurityInheritance]::None +) +$ou_reset_passwords_rule = [System.DirectoryServices.ExtendedRightAccessRule]::New( + $secretop, + [System.Security.AccessControl.AccessControlType]::Allow, + $password_reset_right_guid, + [System.DirectoryServices.ActiveDirectorySecurityInheritance]::Children +) +$acl.AddAccessRule($ou_create_children_rule) +$acl.AddAccessRule($ou_reset_passwords_rule) +Set-ACL -Path $ou_path -AclObject $acl +---- + [#ad-samaccountname] ===== Custom `samAccountName` generation @@ -273,7 +311,7 @@ spec: passwordCacheSecret: namespace: default name: secret-operator-ad-passwords - userDistinguishedName: CN=Users,DC=sble,DC=test + userDistinguishedName: OU=SDP,DC=sble,DC=test schemaDistinguishedName: CN=Schema,CN=Configuration,DC=sble,DC=test adminKeytabSecret: namespace: default @@ -290,8 +328,8 @@ spec: `kerberosKeytab.admin.activeDirectory.ldapServer`:: An AD LDAP server, such as the AD Domain Controller. This _must_ match the server's FQDN, or GSSAPI authentication will fail. `kerberosKeytab.admin.activeDirectory.ldapTlsCaSecret`:: Reference (`name` and `namespace`) to a K8s `Secret` object containing the TLS CA (in `ca.crt`) that the LDAP server's certificate should be authenticated against. `kerberosKeytab.admin.activeDirectory.passwordCacheSecret`:: Reference (`name` and `namespace`) to a K8s `Secret` object where workload passwords will be stored. This _must not_ be accessible to end users. -`kerberosKeytab.admin.activeDirectory.userDistinguishedName`:: The root Distinguished Name (DN) where service accounts should be provisioned, typically `CN=Users,\{domain_dn\}`. -`kerberosKeytab.admin.activeDirectory.schemaDistinguishedName`:: The root Distinguished Name (DN) for AD-managed schemas, typically `CN=Schema,CN=Configuration,\{domain_dn\}`. +`kerberosKeytab.admin.activeDirectory.userDistinguishedName`:: The root Distinguished Name (DN) of the container where service accounts should be provisioned, such as `OU=SDP,\{domain_dn\}`. +`kerberosKeytab.admin.activeDirectory.schemaDistinguishedName`:: The root Distinguished Name (DN) of the container for AD-managed schemas, typically `CN=Schema,CN=Configuration,\{domain_dn\}`. `kerberosKeytab.adminKeytabSecret`:: Reference (`name` and `namespace`) to a K8s `Secret` object where a keytab with administrative privileges is stored in the key `keytab`. `kerberosKeytab.adminPrincipal`:: The name of the Kerberos principal to be used by the Secret Operator. This should be provided by the Kerberos administrator. The credentials for this principal must be stored in the keytab (`adminKeytabSecret`). From 3f6896cc5b6c7c8b63bb237d3d7f546b1f8b2f99 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Natalie=20Klestrup=20R=C3=B6ijezon?= Date: Wed, 15 Jan 2025 16:17:12 +0100 Subject: [PATCH 2/3] Document how to configure the ACL rules manually --- docs/modules/secret-operator/pages/secretclass.adoc | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/docs/modules/secret-operator/pages/secretclass.adoc b/docs/modules/secret-operator/pages/secretclass.adoc index 1ffbfd56..6ad6dfdc 100644 --- a/docs/modules/secret-operator/pages/secretclass.adoc +++ b/docs/modules/secret-operator/pages/secretclass.adoc @@ -225,7 +225,7 @@ If the same AD domain _is_ shared between multiple Kubernetes clusters, the foll The Secret Operator needs permission to create users in the configured base container (`kerberosKeytab.admin.activeDirectory.userDistinguishedName`), as well as to reset their passwords. -This can be configured using the following PowerShell script: +The easiest way to configure this is to run the following PowerShell script: // FIXME: This script is copied from ad-init, can we share this somehow? @@ -257,6 +257,13 @@ $acl.AddAccessRule($ou_reset_passwords_rule) Set-ACL -Path $ou_path -AclObject $acl ---- +Alternatively, it can be configured manually using the graphical "ADSI Edit" tool. Secret Operator's user needs two permission rules +on the base container: + +- On the container itself: Create User objects +- On descendants of the container: Reset Password (this is not visible in the GUI, but is granted by the "All extended rights" toggle) + + [#ad-samaccountname] ===== Custom `samAccountName` generation From 6510c93325ab2b01da4799a46272b0fe416b4a62 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Natalie=20Klestrup=20R=C3=B6ijezon?= Date: Wed, 15 Jan 2025 16:22:40 +0100 Subject: [PATCH 3/3] Add a warning about empty-looking ACL rules --- docs/modules/secret-operator/pages/secretclass.adoc | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/modules/secret-operator/pages/secretclass.adoc b/docs/modules/secret-operator/pages/secretclass.adoc index 6ad6dfdc..617ddcce 100644 --- a/docs/modules/secret-operator/pages/secretclass.adoc +++ b/docs/modules/secret-operator/pages/secretclass.adoc @@ -257,6 +257,11 @@ $acl.AddAccessRule($ou_reset_passwords_rule) Set-ACL -Path $ou_path -AclObject $acl ---- +NOTE: The "reset passwords" rule created by the script will show up as applying no permissions in ADSI Edit. + This is because ADSI Edit is unaware of the extended right that it grants. The rule _should not_ be + deleted or modified manually, or the operator will break. If the rule has been tampered with, run the + script again to fix the problem. + Alternatively, it can be configured manually using the graphical "ADSI Edit" tool. Secret Operator's user needs two permission rules on the base container: