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
For most service types, credentials can be provided. The types of credentials allowed depend on the service type, but generally several are available.
Credential type "none" indicates that the service endpoint does not require any 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".
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".
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.
The Agent supports many services types generally, but the ones shown below are also supported by ISD and Spinnaker.
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
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
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.
Last modified 7mo ago