Implementation steps and assets for Google Cloud Anthos blueprints https://cloud.google.com/architecture/blueprints/anthos-security-blueprints-faq
APACHE-2.0 License
This repository contains the deployable assets that are part of the Google Cloud Security blueprints for Anthos. The Google Cloud Security blueprints for Anthos are granular and address specific security postures.
The instructions and accompanying assets in this repo are for the following Google Cloud Security blueprints for Anthos:
The blueprints can be used in any combination. Note: If you need to constraint what regions your clusters can be deployed to the steps detailed in the Enforcing locality restrictions blueprint should be followed first before using any other Anthos security blueprint.
This repository for the set of blueprints is to be used with a structured Anthos config management repo
Example Anthos config management Structured repo configuration:
── config-root/ # directory ACM monitors for policy
├── README.md
├── system/ # configs for the Operator
├── namespaces/ configs for namespaces and namespace-scoped objects. Structure determines namespace inheritance
├── cluster/ # configs for cluster scoped objects
| | - # Put Your Policy Controller constraints here
└── clusterregistry/ # configs for cluster selectors - limits which clusters a config applies to
├── cluster.mycluster.yaml
├── clusterregistry.select-location-clusterx.yaml
└── clusterregistry.select-prod.yaml
We recommend you read through the full README but if you just want to get started
If you have already implemented one of the Anthos specific blueprints for your Anthos clusters in this series you do not need to repeat the prerequisites and deployment steps described in this README
The blueprints outlined in this repo are additive so you can apply multiple blueprints to your clusters.
Follow through the detailed deployment steps for each individual blueprint by following the steps detailed in the README for the specific blueprint folder.
If you wish to start from an end to end example follow the steps outlined in the example README that mostly closely meets the security posture you wish to apply to your clusters.
Note: each blueprint in the series assumes you have Policy Controller installed which is a recommendation in the hardening guides
You can use Cloud Shell, a local machine or VM as your admin workstation
Tools for Cloud Shell as your Admin workstation
Tools for a local workstation as your Admin workstation
Installation instructions for Tools for your environment
This is pre installed if you are using Cloud Shell
The Google Cloud SDK is used to interact with your GCP resources. Installation instructions for multiple platforms are available online.
The kubectl CLI is used to interact with both Kubernetes Engine and kubernetes in general. Installation instructions for multiple platforms are available online.
Install the nomos CLI for managing ACM across clusters
Terraform is used to automate the manipulation of cloud infrastructure. Its installation instructions are also available online. When configuring terraform for use with Google cloud create a service account as detailed in Getting started with the google provider
After installing the gcloud SDK run gcloud init to set up the gcloud cli. When executing choose the correct region and zone
'gcloud init'
Ensure you are using the correct project . Replace my-project-name with the name of your project
Where the project name is my-project-name
gcloud config set project my-project-name
Important :If you are implementing multiple blueprints you only need to clone the repo once
In your terminal, clone this repo locally.
$ git clone https://github.com/<GITHUB\_USERNAME>/xyz.git
$ cd xyz/docs/
For production configurations ensure you have configured a centralised repo such as Cloud Source Repositories, GitHub, Gitlab for use with Anthos Config manager.
Important : You only need to do this step once per cluster
The ACM Operator must be given read access to git and configured to read from a git repository. \
It is recommended to use a deploy key to authenticate the ACM Operator with git. Using a deploy key attaches the public part of the key directly to the repo rather than to a personal user account.
Create a ssh keypair and register the public key with your git hosting provider.
# create ssh key
ssh-keygen -t rsa -N '' -b 4096 -C <git_username> -f ~/.ssh/id_rsa.acm
# add key to your ssh agent
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa.acm
#### add contents of public key ~/.ssh/id_rsa.acm.pub to the repo in the github account you are using for your configs
#### github.com > Your Profile > Repositories > Settings > Deploy Keys > Add Deploy Key
Paste in contents
# Set write access
Select Allow write access
Click Add Key
# verify access
ssh -i /path/to/private/key [email protected]
Hi <git username>! You've successfully authenticated, but GitHub does not provide shell access.
Add the private key to a secret "git-creds" in each of your clusters.
# create secret in operator
kubectl create secret generic git-creds \
--namespace=config-management-system \
--from-file=ssh=~/.ssh/id_rsa.acm
Each cluster's ACM operator must be configured to point to the config-root in anthos-security-blueprints
Each cluster has its own config in the [setup/] directory.
git:
syncRepo: [email protected]:[email protected]/csp-config-management.git
If you are using another git repo amend accordingly
# Get kubeconfig credentials for your cluster
$ gcloud container clusters get-credentials <cluster name> --zone <cluster zone>
# Ensure kubectl is using correct context
$ kubectl config get-context
# Apply the configuration to your cluster
$ kubectl apply -f setup/<cluster name>.config-management.yaml
Confirm the sync was successful with nomos status
For each cluster you should see the status set to SYNCED