Skip to content

Latest commit

 

History

History

namespace-inheritance

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 

Config Sync Namespace Inheritance Example

This example demonstrates how to use namespace inheritance with the hierarchical format in Config Sync.

It contains three simple use cases:

  • Inherited default NetworkPolicies can be customized by adding a second object in an individual namespace.
  • Default RoleBindings can be inherited across multiple namespaces in cases ClusterRoleBindings are too broad.
  • Default ResourceQuota can be overridden using NamespaceSelectors.

Before you begin

Viewing the compiled configs in the repo

You can use the nomos hydrate command to view the combined contents of your repo on each enrolled cluster. This example stores the output from nomos hydrate in a compiled/ directory to illustrate what hierarchical mode actually does under the covers.

Configuring syncing from the repository

You can configure syncing from the Git repository using GCP console or gcloud.

Using GCP Console

Following the console instructions for configuring Config Sync, you need to

  • Select None in the Git Repository Authentication for ACM section
  • Select Enable Config Sync in the ACM settings for your clusters section
    • If you're using your forked repo, the URL should be the Git repository url for your fork: https://github.com/<YOUR_ORGANIZATION>/anthos-config-management-samples.git; otherwise the URL should be https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git
    • the Branch should be init.
    • the Tag/Commit should be HEAD.
    • the Source format field should hierarchy.
    • the Policy directory field should be namespace-inheritance/config.

Using gcloud

You can also configure the Git repository information in a config-management.yaml file and use a gcloud command to apply the file.

  1. Create a file named config-management.yaml and copy the following YAML file into it:
    # config-management.yaml
    
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
     name: config-management
    spec:
     sourceFormat: hierarchy
     git:
       syncRepo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples/
       syncBranch: init
       secretType: none
       policyDir: namespace-inheritance/config
  2. Apply the config-management.yaml file:
    gcloud beta container fleet config-management apply \
        --membership=CLUSTER_NAME \
        --config=CONFIG_YAML_PATH \
        --project=PROJECT_ID

Replace the following:

  • CLUSTER_NAME: the name of the registered cluster that you want to apply this configuration to
  • CONFIG_YAML_PATH: the path to your config-management.yaml file
  • PROJECT_ID: your project ID

Verifying the installation

Using GCP Console

  1. In the Cloud Console, go to the Anthos Config Management page.
  2. View the Status column. A successful installation has a status of Synced.

Using gcloud

Run the following command to get the status

gcloud beta container fleet config-management status --project=PROJECT_ID

Replace PROJECT_ID with your project's ID.

A successful installation has a status of SYNCED.

Using nomos

Run the following command to get the status

nomos status

Example Output:

*your-cluster
  --------------------
  <root>   https://github.com/GoogleCloudPlatform/anthos-config-management-samples/namespace-inheritance/config@init   
  SYNCED   c4fee081 

Examining your configs

The config directory includes ClusterRoles, ClusterRoleBindings, Namespaces, Roles, RoleBindings, NetworkPolicies, ResourceQuotas, and NamespaceSelectors. These configs are applied as soon as the Config Sync is configured to read from the repo.

All objects managed by Config Sync have the app.kubernetes.io/managed-by label set to configmanagement.gke.io.

  • List namespaces managed by Config Sync

    kubectl get ns -l app.kubernetes.io/managed-by=configmanagement.gke.io

    Example Output:

    NAME          STATUS   AGE
    analytics     Active   7h10m
    gamestore     Active   7h10m
    incubator-1   Active   7h10m
    incubator-2   Active   7h10m
  • List roles managed by Config Sync

    kubectl get roles -A -l app.kubernetes.io/managed-by=configmanagement.gke.io

    Example Output:

    NAMESPACE     NAME                CREATED AT
    analytics     eng-viewer          2021-04-28T19:10:43Z
    gamestore     eng-viewer          2021-04-28T19:10:43Z
    incubator-1   incubator-1-admin   2021-04-28T19:18:17Z

    Explanation:

    • The eng-viewer roleb is created in namespaces under the eng abstract namespace directory because it is inherited from config/namespaces/eng/eng-role.yaml.
    • The incubator-1-admin role is created in the incubator-1 namespace because of the config config/namespaces/rnd/incubator-1/incubator-1-admin-role.yaml.
  • List rolebindings managed by Config Sync

    kubectl get rolebindings -A -l app.kubernetes.io/managed-by=configmanagement.gke.io

    Example Output:

    NAMESPACE     NAME               ROLE                    AGE
    analytics     eng-admin          Role/eng-viewer         10m
    analytics     viewers            ClusterRole/view        18h
    gamestore     bob-rolebinding    ClusterRole/foo-admin   18h
    gamestore     eng-admin          Role/eng-viewer         10m
    gamestore     viewers            ClusterRole/view        18h
    incubator-1   viewers            ClusterRole/view        19h
    incubator-2   viewers            ClusterRole/view        19h

    Explanation:

    • The viewers rolebinding is created in all managed namespaces because it is inherited from config/namespaces/viewers-rolebinding.yaml.
    • The eng-admin rolebinding is created in namespaces under the eng abstract namespace directory because it is inherited from config/namespaces/eng/eng-rolebinding.yaml.
    • bob-rolebinding is created in the gamestore namespace because of the config config/namespaces/eng/gamestore/bob-rolebinding.yaml.
  • List networkpolicies managed by Config Sync

    kubectl get networkpolicies.networking.k8s.io -A -l app.kubernetes.io/managed-by=configmanagement.gke.io

    Example Output:

    NAMESPACE     NAME                       POD-SELECTOR    AGE
    analytics     allow-gamestore-ingress    app=gamestore   7h17m
    analytics     default-deny-all-traffic   <none>          7h17m
    gamestore     allow-gamestore-ingress    app=gamestore   7h17m
    gamestore     default-deny-all-traffic   <none>          7h17m
    incubator-1   default-deny-all-traffic   <none>          7h17m
    incubator-2   default-deny-all-traffic   <none>          7h17m

    Explanation:

    • The default-deny-all-traffic networkpolicy is created in all managed namespaces because it is inherited from config/namespaces/network-policy-default-deny-all.yaml.
    • The allow-gamestore-ingress networkpolicy is created in namespaces under the eng abstract namespace directory because it is inherited from config/namespaces/eng/network-policy-allow-gamestore-ingress.yaml. Ingress traffic will be allowed only to Pods in the gamestore namespace with the app:gamestore label.
  • List resourcequotas managed by Config Sync

    kubectl get resourcequotas -A -l app.kubernetes.io/managed-by=configmanagement.gke.io

    Example Output:

    NAMESPACE   NAME    AGE     REQUEST                                   LIMIT
    analytics   quota   7h19m   cpu: 0/100m, memory: 0/100Mi, pods: 0/1   
    gamestore   quota   7h19m   cpu: 0/200m, memory: 0/200Mi, pods: 0/1  

    Explanation:

    • The quota resourcequota is created in the analytics namespace because the analytics-selector limits which namespaces can inherit that config.
    • The quota resourcequota is created in the gamestore namespace because the gamestore-selector limits which namespaces can inherit that config.