Infrastructure definition for CI/CD environments.
To add a new repo to CI,
- add the repo to
REPOS
in wf-gen/common.zsh - run wf-gen/prs.zsh for all repos
- get all your PRs merged
To add a new repo to CD,
- add it to the
local.repos
in base/base.tf - plan, apply there
- add a sensible default value to a new variable for the repo in infra/variables.tf
- add it to
local.repos
in infra/infra.tf - plan, apply there
- add a definition of the service to devenv/terraform in the gromit repo
- make new release of gromit
- let the CD on this repo deploy the new gromit release
To manage the meta-automation which keeps the automation managed by prs.zsh
in sync across release branches,
- review wf-gen/meta.zsh
- run it
Contains the AWS Resources that require privileged access like IAM roles. These resources have a lifecycle separate from the infra and are stored in a separate state on Terraform Cloud.
Contents:
- vpc
- ECR repos
- ECS Task roles
- EFS filesystems for Tyk config (
config
) and Tyk PKI (certs
)
See base/*.auto.tfvars for the actual values being used right now.
Given a vpc cidr of 10.91.0.0/16, we create,
- a /24 private subnet per az
- a /24 public subnet per az
- a nat gw for internet access from the private subnets
- igw for the public subnets
Registries are created with mutable tags and no automated scanning.
IAM users are created per-repo and given just enough access to access their repo with an inline policy. The users can login, push and pull images for just their repo.
The access key_ids and secrets are stored in the terraform state. Use terraform output
to see the values.
This is used to hold all the configuration data requierd for the services. This is mounted on the mongo instance as well as all the containers. To repeat, the same fs is mounted on all containers.
- add a permission boundary on the IAM users (paranoia)
Contains the components required to support a Tyk installation. These resources have a lifecycle separate from the developer environments and are stored in a separate state on Terraform Cloud.
Adds a bastion host in the public subnet with alok's key. The EFS filesystems are mounted here. The tyk
group has access to the config directories in /config
. Login to the bastion to change the config or to create new config groups.
Adds the newest bitnami mongo image (4.2 in June 2020) on a t3.micro
instance.
In certs
.
There is a self-signed root CA which is used for all resources and for revocations.
% cd rootca
% cfssl gencert -initca csr.json | cfssljson -bare rootca
will generate rootca-key.pem
, rootca.pem
, and rootca.csr
(for cross-signing).
Policies are defined in rootca/config.json
for server, peer, and client roles. The authentication key can be generated with openssl rand -hex 16
and set in CFSSL_API_KEY
. A Dockerfile to provision the newest cfssl is in ca
.
% cd sshca
# Generate pair
% cfssl genkey -initca csr.json | cfssljson -bare ssh
# Sign cert with root CA
% cfssl sign -ca=../rootca/rootca.pem -ca-key=../rootca/rootca-key.pem -config=config.json -profile peer ssh.csr | cfssljson -bare ssh
Define the request in csr.json
.
{
"CN": "cd.tyk.technologies",
"hosts": [
"cd.dev.tyk.technologies",
"localhost"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "UK",
"L": "London",
"O": "Tyk Technologies",
"OU": "Devops",
"ST": "Greater London"
}
]
}
Now request for the certpair to be signed using the server profile by using the config in cfssl-sign.json
.
% CFSSL_API_KEY=xxxxx cfssl gencert -profile=server -config cfssl-sign.json csr.json | cfssljson -bare server
2020/06/26 13:11:29 [DEBUG] loading configuration file from config.json
2020/06/26 13:11:29 [DEBUG] match remote in profile to remotes section
2020/06/26 13:11:29 [DEBUG] match auth key in profile to auth_keys section
2020/06/26 13:11:29 [DEBUG] validating configuration
2020/06/26 13:11:29 [DEBUG] validate remote profile
2020/06/26 13:11:29 [DEBUG] profile is valid
2020/06/26 13:11:29 [DEBUG] configuration ok
2020/06/26 13:11:29 [INFO] generate received request
2020/06/26 13:11:29 [INFO] received CSR
2020/06/26 13:11:29 [INFO] generating key: rsa-2048
2020/06/26 13:11:29 [DEBUG] generate key from request: algo=rsa, size=2048
2020/06/26 13:11:29 [INFO] encoded CSR
2020/06/26 13:11:29 [DEBUG] validating configuration
2020/06/26 13:11:29 [DEBUG] validate remote profile
2020/06/26 13:11:29 [DEBUG] profile is valid
2020/06/26 13:11:29 [DEBUG] validating configuration
2020/06/26 13:11:29 [DEBUG] validate remote profile
2020/06/26 13:11:29 [DEBUG] profile is valid
This will give you server-key.pem
, server.pem
and server.csr
. Use these as you will.
The csr.json
for the server can be re-used but you'll want to remove the hests entries. Or start with cfssl print-defaults csr > csr.json
.
Then, request for signing as above except use -profile=client
.
- keys
- certs
- CSR definitions in JSON form
- signing policy for
cfssl.dev.tyk.technology