Using local asset repositories ¶
You can configure kOps to provision a cluster to download assets (images and files) from local repositories. This is useful when downloading assets from the internet is undersirable, for example:
- To deploy where the network is offline or internet-restricted.
- To avoid rate limits or network transfer costs.
- To limit exposure to watering-hole attacks.
- To comply with other security requirements, such as the need to scan for vulnerabilities.
There can be one repository for images and another for files.
Configuring a local image repository ¶
To configure a local image repository, set either
assets.containerProxy in the cluster spec.
They both do essentially the same thing, but
containerRegistry avoids using
/ characters in the local image names.
Configuring a local file repository ¶
To configure a local file repository, set
assets.fileRepository in the cluster spec.
The repository must allow nodes to perform unauthenticated reads. The repository can be public or it can allow read access through network connectivity, such as access through a particular AWS Endpoint.
Copying assets into repositories ¶
You can copy assets into their repositories either by running
kops get assets --copy or through an external process.
kops get assets --copy, kOps copies assets into their respective repositories if
they do not already exist there.
For file assets, kOps only supports copying to a repository that is either an S3 or GCS bucket.
An S3 bucket must be configured using the regional naming conventions of S3.
A GCS bucket must be configured with a prefix of
Listing assets ¶
You can obtain a list of image and file assets used by a particular cluster by running
kops get assets. You can get output in table, YAML, or JSON format.
You can feed this into a process, external to kOps, for copying the assets to their respective repositories.