Agent Service Configuration

Agent Service Configuration

Services are configured from the "opsmx-services-agentX" user-supplied configmap. There should be one key, 'services.yaml', which defines the services this Agent advertises to ISD, and the credentials needed to provide access.

The "name" element is advertised to ISD, and will be the name used for the associated Spinnaker account configuration. This name will be presented to ISD users. Renaming an account is not possible, and will require deleting and re-creating the account through the ISD interface.

Only services explicitly marked as "enabled: true" will be advertised to Spinnaker.

Example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: opsmx-services-agent1
  namespace: opsmx-agent-agent1
  labels:
    agent.opsmx.com/name: agent1
    agent.opsmx.com/role: agent
data:
  services.yaml: |
    services:
      - name: dev jenkins
        type: jenkins
        enabled: true
        config:
          url: https://dev.jenkins.example.com:8080
          credentials:
            type: basic
            secretName: dev-jenkins-secret
      - name: artifactory-test
        type: artifactory
        enabled: true
        config:
          url: https://artifactory.example.com
          credentials:
            type: bearer
            secretName: artifactory-secret
      - name: kubernetes1
        type: kubernetes
        enabled: true
        namespaces:
          - name: kubernetes1-ns-test
            namespaces:
              - test
          - name: kubernetes-ns-default
            namespaces:
              - default
              - test

Agent Service Credentials

For most service types, credentials can be provided. The types of credentials allowed depend on the service type, but generally several are available.

No authentication

Credential type "none" indicates that the service endpoint does not require any authentication.

HTTP Basic Authentication

A credential type of "basic" requires a username and a password to be provided in the configmap or in a Kubernetes secret. These are passed to the target via HTTP Basic authentication.

If secrets are provided in the configmap (not recommended) they must be base64 encoded.

Example (with literal contents, not recommended):

services:
      - name: dev jenkins
        type: jenkins
        enabled: true
        config:
          url: https://dev.jenkins.example.com:8080
          credentials:
            type: basic
            username: bm90LWEtZ29vZC11c2VybmFtZQ==
            password: YWxzby1ub3QtZ29vZC1wYXNzd29yZA==

Example (with Kubernetes secret of type 'kubernetes.io/basic-auth'):

services:
      - name: dev jenkins
        type: jenkins
        enabled: true
        config:
          url: https://dev.jenkins.example.com:8080
          credentials:
            type: basic
            secretName: dev-jenkins-secret

The secret must be created, and have keys for "username" and "password".

HTTP Bearer Authentication

A credential type of "bearer" requires a token to be provided in the configmap or in a Kubernetes secret. These are passed to the target via HTTP Bearer authentication.

If secrets are provided in the configmap (not recommended) they must be base64 encoded.

Example (with literal contents, not recommended):

services:
      - name: dev jenkins
        type: jenkins
        enabled: true
        config:
          url: https://dev.jenkins.example.com:8080
          credentials:
            type: bearer
            token: YWxzby1ub3QtZ29vZC1wYXNzd29yZA==

Example (with Kubernetes secret of type Opaque):

services:
      - name: dev jenkins
        type: jenkins
        enabled: true
        config:
          url: https://dev.jenkins.example.com:8080
          credentials:
            type: bearer
            secretName: dev-jenkins-secret

The secret must be created, and have a key for "token".

HTTP "Token" Authentication

While "bearer" should generally be used, some services require a small change, and require the authentication type to be called "token" in the HTTP headers sent to authenticate. Other than that change, "token" and "bearer" are identical in configuration methods.

Agent Service Type

The Agent supports many services types generally, but the ones shown below are also supported by ISD and Spinnaker.

Jenkins

Authentication types: none, basic, bearer. Example configuration:

services:
      - name: dev jenkins
        type: jenkins
        enabled: true
        config:
          url: https://dev.jenkins.example.com:8080
          credentials:
            type: bearer
            secretName: dev-jenkins-secret

Artifactory

Authentication types: none, basic, bearer. Example configuration:

services:
      - name: artifactory1
        type: artifactory
        enabled: true
        config:
          url: https://artifactory.example.com
          credentials:
            type: basic
            secretName: artifactory1-secret

Kubernetes

The agent has the ability to manage any namespace in the Kubernetes cluster it is installed into. However, it is disabled by default.

The Kubernetes service can be configured in two ways: a single Kubernetes account is advertised to Spinnaker, or multiple accounts with the same credentials advertised to Spinnaker, with different namespaces.

In all cases, access control is provided based on the Spinnaker configuration for RBAC.

Multiple clusters are not supported at this time, but multiple agents can be used, one per cluster. The namespace restrictions in the following examples are views into a single cluster, the one where the agent is running.

To advertise a single Kubernetes account "kubernetes1" which provides access to all namespaces:

  services:
      - name: kubernetes1
        type: kubernetes
        enabled: true

To advertise a multiple Kubernetes accounts, with specific namespaces and names:

services:
      - name: kubernetes1
      type: kubernetes
        enabled: true
        namespaces:
          - name: kubernetes1-ns-test
            namespaces:
              - test
          - name: kubernetes-ns-default
            namespaces:
              - default
              - test

When advertising multiple instances, the top-level name is ignored.