Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pass BotKube communication settings as a K8s Secret #211

Closed
PrasadG193 opened this issue Nov 7, 2019 · 3 comments · Fixed by #226 or #233
Closed

Pass BotKube communication settings as a K8s Secret #211

PrasadG193 opened this issue Nov 7, 2019 · 3 comments · Fixed by #226 or #233
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@PrasadG193
Copy link
Collaborator

Is your feature request related to a problem? Please describe.
BotKube config contains sensitive info like Tokens which is passed to backend via ConfigMap. We should pass the communication setting as a K8s Secret. Also, restrict BotKube to access Secret resources using @BotKube commands by default

@PrasadG193 PrasadG193 added the enhancement New feature or request label Nov 7, 2019
@PrasadG193 PrasadG193 changed the title Use secrets to pass BotKube communication settings Pass BotKube communication settings as a K8s Secret Nov 7, 2019
@PrasadG193 PrasadG193 added the good first issue Good for newcomers label Nov 12, 2019
@slalwani97
Copy link
Contributor

slalwani97 commented Nov 28, 2019

Would like to check my approach first before implementing:

  1. Move communication settings to secret.
apiVersion: v1
kind: Secret
metadata:
  name: botkube-secret
type: Opaque
stringData:
  communication.yaml: |
    # Communication settings
    communications:
      # Settings for Slack
      slack:
        enabled: false
        channel: 'SLACK_CHANNEL'
        token: 'SLACK_API_TOKEN'
        notiftype: short                            # Change notification type short/long you want to receive. notiftype is optional and Default notification type is short (if not specified)

      # Settings for Mattermost
      mattermost:
        enabled: false
        url: 'MATTERMOST_SERVER_URL'                # URL where Mattermost is running. e.g https://example.com:9243
        token: 'MATTERMOST_TOKEN'                   # Personal Access token generated by BotKube user
        team: 'MATTERMOST_TEAM'                     # Mattermost Team to configure with BotKube
        channel: 'MATTERMOST_CHANNEL'               # Mattermost Channel for receiving BotKube alerts
        notiftype: short                            # Change notification type short/long you want to receive. notiftype is optional and Default notification type is short (if not specified)

      # Settings for ELS
      elasticsearch:
        enable: false
        server: 'ELASTICSEARCH_ADDRESS'              # e.g https://example.com:9243
        username: 'ELASTICSEARCH_USERNAME'
        password: 'ELASTICSEARCH_PASSWORD'
        # ELS index settings
        index:
          name: botkube
          type: botkube-event
          shards: 1
          replicas: 0

      # Settings for Webhook
      webhook:
        enabled: false
        url: 'WEBHOOK_URL'                          # e.g https://example.com:80
  1. This will be mounted as a seperate file so this file should be read and unmarshal into config structure.
// New returns new Config
func New() (*Config, error) {
	c := &Config{}
	configPath := os.Getenv("CONFIG_PATH")
	configFilePath := filepath.Join(configPath, ConfigFileName)
	communicationFilePath := filepath.Join(configPath, communicationFileName)
	configFile, err := os.Open(configFilePath)
	defer configFile.Close()
	if err != nil {
		return c, err
	}

	b, err := ioutil.ReadAll(configFile)
	if err != nil {
		return c, err
	}

	if len(b) != 0 {
		yaml.Unmarshal(b, c)
	}

	communicationFile, err = os.Open(communicationFilePath)
	defer communicationFile.Close()
	if err != nil {
		return c, err
	}

	b, err = ioutil.ReadAll(file)
	if err != nil {
		return c, err
	}

	if len(b) != 0 {
		yaml.Unmarshal(b, c)
	}
	return c, nil
}

@PrasadG193 Is this the correct approach?

@PrasadG193
Copy link
Collaborator Author

@slalwani97 Sounds good to me.
Just a thought, while unmarshalling communication content, we can unmarshal it into Communications{} struct instead of Config{}
Can you please raise a PR? That will make it easier to do review and discuss.

@slalwani97
Copy link
Contributor

@PrasadG193 PTAL: #226

@PrasadG193 PrasadG193 reopened this Dec 19, 2019
mergify bot pushed a commit that referenced this issue May 25, 2021
)

##### ISSUE TYPE
 - Feature Pull Request

##### SUMMARY
I have implemented in the helm chart the possibility to pass the communication config as a k8s secret and configure in the value files via an existingSecret. It can be configured in the values file via these:

```yaml
communications:
    existingSecret: false
    existingSecretName: ""
```

Fixes #319 #211 #226 #233
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
2 participants