Unstructured mode is an Anthos Config Management (ACM) policy-repository format. It lets developers and administrators choose which namespaces receive resources without requiring a namespace hierarchy. That flexibility comes with an obligation to specify the intended namespace or namespaces. Hierarchy is the default format; select unstructured with the operator configuration’s `spec.sourceFormat` setting. section 11.5 section 11.2.1
The policy directory still defines Kubernetes objects for the ACM operator to examine and apply to connected clusters. Unlike a hierarchy repository, an unstructured repository does not mandate a particular directory organization. Teams can arrange policies around ownership and control access to folders accordingly. section 11.2.1 section 11.3.1
Choose the format with its deployment consequences in mind:
- Use unstructured mode when explicit namespace targeting and compatibility with existing templating workflows matter more than hierarchy-based propagation. section 11.5
- Keep generated YAML or JSON in the policy repository when existing tools produce the configuration but ACM should perform deployment and management. section 11.2
- Review folder permissions and proposed changes even when teams cannot modify one another’s or global policies; access restrictions reduce, but do not eliminate, review. section 11.3.1
Team-owned policies and production access
An operations team can place global policies and team-owned application configurations in separate repository folders. A `production` NamespaceSelector matches namespaces labeled `env: production`; a developer Role references that selector to assign its permissions to the matching namespaces. For releases, a Helm-based workflow can write generated configuration to the ACM repository and submit a pull request instead of deploying directly to production. section 11.3.1
applySpecVersion: 1
spec:
clusterName: <name of cluster>
enableMultiRepo: <true/false, enables multiple repository mode>
enableLegacyFields: <true/false, used with multi repo, see below>
policyController:
enabled: <true/false>
templateLibraryInstalled: <true/false, installs the Google-provided template library for policy controller>
sourceFormat: <hierarchy or unstructured. Sets the type of policy organization>
preventDrift: <if set to true, rejects changes to the cluster that conflict with managed resources>
git:
syncRepo: <url of the git repository>
syncBranch: <branch of the git repository to sync from>
policyDir: <relative path in the git repository to the policy directory>
syncWait: <number of seconds between sync attempts>
syncRev: <git revision to sync from. Used if a specific commit or tag should be used instead of a branch>
secretType: <ssh, cookiefile, token, gcenode, gcpserviceaccount or none. Specifies the type of authentication to perform>
gcpServiceAccountEmail: <email of the service account to use for git access. Only used when secretType is gcpserviceaccount>
proxy:
httpProxy: <proxy information for http connection, styled similarly to the HTTP_PROXY environment variable>
httpsProxy: <proxy information for https connection, styled similarly to the HTTPS_PROXY environment variable>
The operator configuration identifies `sourceFormat`, the Git policy directory, and the repository sync settings used to operate this mode. section 11.2
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: prod-developer annotations: configmanagement.gke.io/namespace-selector: production rules: - apiGroups: [""] resources: ["pods", "configmaps"] verbs: ["get", "watch", "list"] - apiGroups: ["apps", "extensions"] resources: ["deployments", "replicasets"] verbs: ["get", "watch", "list"] - apiGroups: [""] resources: ["secrets"] verbs: ["list"]
The Role manifest illustrates a resource annotated with a named NamespaceSelector for production namespaces. section 11.3.1
