Armory Agent Configuration Options

Where to configure the Agent

Set these options at the agent level in the kubesvc.yaml configuration file. If deploying as a non-Spinnaker^TM service, you need to specify a clouddriver.grpc endpoint (e.g. grpc.spinnaker.example.com:443).

Kubernetes account

At a minimum you will need to add an account, give it a name, and set its Spinnaker permissions.

Spinnaker Service and Infrastructure modes

In these modes, you set up multiple accounts per agent. Your configuration should look like:

kubernetes:
  accounts:
    - name: account-01
      kubeconfigFile: /kubeconfigfiles/kubecfg-account01.yaml
    - ...  

If you are migrating accounts from Clouddriver, you can just copy the same block of configuration here. Unused properties are ignored.

Agent mode

In agent mode, your configuration should look like:

kubernetes:
  accounts:
    - name: account-01
      serviceAccount: true

Options

Restricted Environments

Network Access

The Agent needs access to its control plane (Spinnaker) as well to the various Kubernetes clusters it is configured to monitor. You can control which traffic should go through an HTTP proxy via the usual HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables.

A common case is to force the connection back to the control plane via a proxy but bypass it for Kubernetes clusters. In that case, define the environment variable HTTPS_PROXY=https://my.corporate.proxy and use the kubernetes.noProxy: true setting to not have to maintain the list of Kubernetes hosts in NO_PROXY.

Kubernetes Authorization

The Agent should be configured to access each Kubernetes cluster it monitors with a service account. You can limit what Spinnaker can do via the role you assign to that service account. For example, if you’d like Spinnaker to see NetworkPolicies but not deploy them:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: agent-role
rules:
- apiGroups: ["networking.k8s.io"]
  resources: ["networkpolicies"]
  verbs: [ "get", "list", "watch"]
...

Namespace Restrictions

You can limit the Agent to monitoring specific namespaces by listing them under namespaces. If you need to prevent the Agent from accessing cluster-wide (non-namespaced) resources, use the onlyNamespacedResources setting.

A side effect of disabling cluster-wide resources is that CustomResourceDefinitions won’t be known (and therefore deployable by Spinnaker). CustomResourceDefinitions are cluster-wide resources, but the custom resources themselves may be namespaced. To workaround the limitation, you can define customResourceDefinitions. Both namespaces and CRDs will be sent to Spinnaker as “synthetic” resources. They won’t be queried or watched, but their existence will be known by Spinnaker.

kubernetes:
    accounts:
        - name: production
          ...
          # Restricts the agent to namespaces `ns1` and `ns2`
          namespaces:
            - ns1
            - ns2
          # Prevents the Agent from querying non-namespaced resources
          onlyNamespacedResources: true
          # Whitelist CRDs so Spinnaker
          customResourceDefinitions:
            - kind: ServiceMonitor.monitoring.coreos.com
            - kind: SpinnakerService.spinnaker.armory.io

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.