Just a quick blog post on how to authenticate Docker to a Harbor Image Registry, using a Robot Account, which is good for programmatically access to push/pull images from your registry.
Harbor introduced the capability for administrators to create system robot accounts you can use you run automated actions in your Harbor instances. System robot accounts allow you to use a robot account to perform maintenance or repeated task across all or a subset of projects in your Harbor instance.
A while ago I was chatting to Michael Cade, and we pondered the question “How do we ensure Kasten is protecting a newly deployed application in our Kubernetes environment”.
We chatted about how one of the best ways to make your Kasten protection policy flexible is by using metadata labels.
We came up with the simple idea: “What if something forces a known label on the metadata of any applications deployed by our developers in the future?”
This blog post covers this use case using Tanzu Mission Control with custom policies.
One of the products we can use to enforce labels on a Kubernetes resource is Open Policy Agent Gatekeeper. Which is an external admission controller which allows you to create policies for the admission of resource creation/changes/updates based on a criteria.
OPA policies are expressed in a high-level declarative language called Rego. (Pronounced “ray-go”.)
Tanzu Mission Control, the fleet management SaaS tool for managing your Kubernetes platforms, provides you the ability to create policies of various types to manage the operation and security posture of your Kubernetes clusters and other organizational objects, implemented by using the OPA Gatekeeper.
This walk-through will detail the technical configurations for using vRA Code Stream to deploy Red Hat OpenShift Clusters, register them as Kubernetes endpoints in vRA Cloud Assembly and Code Stream, and finally register the newly created cluster in Tanzu Mission Control.
The deployment uses the Installer Provisioned Infrastructure method for deploying OpenShift to vSphere. Which means the installation tool “openshift-install” provisions the virtual machines and configures them for you, with the cluster using internal load balancing for it’s API interfaces.
Whilst working with vRA to deploy various Kubernetes clusters and then register them with Tanzu Mission Control (TMC), I decided to use Postman (a great API Explorer tool) to catalogue my work and build out several use cases.
Where the requests require some changes in the body that is best not to have as a variable, such as naming a backup, I’ve also tried to add information on the documentation.
Under the Login folder, run “Get Access Token”, which will connect to your TMC URL and use the CSP Refresh Token to generate an Access Token, this access token will be committed to a variable called “accessToken” for use with the other requests.
You will also probably want to run the “Get Organisation ID” as some of the requests require your Org ID, so this will commit it to a variable. This is gathered by looking at the details for your given CSP Token.
If you are running the API to attach a new cluster. Then you will want to run the second request “Get TMC Agent Installer information” which will give you the Installer Link to run in your Kubernetes environment. This data will be written to a variable.
For most of the request that List information, you can use the query “?searchScope.name=” with the API call to filter for necessary objects, or you can use the wildcard value *. I’ve added most of the search filters and value formatters to the requests.
To get the full details for a particular named cluster, I have written the queries for specified clusters, this requires you to provide the management cluster and provisioner of that specified cluster in the query. Essentially it returns the same information as the “Get Clusters List” combined with the SearchScope filter.
So, I won’t describe every set of requests I’ve created. I’ve tried to create these with the bare minimum information you need especially for the POST methods.
If you want to explore the APIs more, you can download an import the Swagger/Open API spec from VMware yourself and import into Postman, but personally I found this hard to work with, and the example bodies give you everything including the responses you won’t need for a POST.
If you’d like to contribute, please do this via the GitHub link!
Looking for more resources around TMC? Then you can check out my other blogs!
In this blog post, I am going to cover the new support for Tanzu Kubernetes Grid Management clusters on both VMware Cloud on AWS (VMC) and Azure VMware Solution (AVS). This functionality also allows the provisioning of new Tanzu Kubernetes workload clusters (TKC) to the relevant platform, provisioned by the lifecycle management controls within Tanzu Mission Control.
Below are the other blog posts I’ve wrote covering Tanzu Mission Control.
Below are the relevant release notes for the features I’ll cover. In this blog post, I’ll just be showing screenshots for a VMC environment, however the same applies to AVS as well.
What's New May 26, 2021
New Features and Improvements
(New Feature update): Tanzu Mission Control now supports the ability to register Tanzu Kubernetes Grid (1.3 & later) management clusters running in vSphere on Azure VMware Solution.
What's New April 30, 2021
New Features and Improvements
(New Feature update): Tanzu Mission Control now supports the ability to register Tanzu Kubernetes Grid (1.2 & later) management clusters running in vSphere on VMware Cloud on AWS. For a list of supported environments, see Requirements for Registering a Tanzu Kubernetes Cluster with Tanzu Mission Control in VMware Tanzu Mission Control Concepts.
This first management cluster deployment is not supported by TMC, nor is it supported for a management cluster to deploy workload clusters across platforms. For example, a management cluster running in AWS does not have the capability to deploy workload clusters to VMC or AVS or Azure.