-
Notifications
You must be signed in to change notification settings - Fork 11
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
Add Annotation parsing and Config from Annotations functions #359
Conversation
efbcf5a
to
6a3a84c
Compare
6a3a84c
to
c0d76ca
Compare
Includes Annotation Parser, custom error and info messages, and unit tests.
- Convert tests from Convey to vanilla Go unit testing, for both Annotations and Config packages - Refactor ParseAnnotations function to remove unit test dependency on file system operations
- Move annotation key and value validation to config package. The annotations package should only parse - validation is the responsibility of the consuming entity. - Consolidate NewFromEnv, NewFromAnnotations, and MergeConfig into one function, NewConfig. Helps solve problems that arise from handling Configs compiled from different sources that are dependent on each other. - Update unit tests to reflect these changes.
859523a
to
379477f
Compare
Validate annotation key-values and Secrets Provider config separately
379477f
to
6f45dce
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice job weaving all of the different pieces of the configuration together (SP env variables, authn-k8s env variables, Annotations)! The resulting flow is pretty easy to follow, and it looks like you've covered all of the edge cases.
Nice work on the table-driven test cases and the use of closure for the assertion funcs!
I just have minor comments and some just-for-grins color commentary. Otherwise looks good-to-go.
printErrorAndExit(messages.CSPFK049E) | ||
} | ||
|
||
secretsProviderSettings := secretsConfigProvider.GatherSecretsProviderSettings(annotationsMap) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work on fitting together all of the config puzzle pieces here.
"github.com/cyberark/secrets-provider-for-k8s/pkg/log/messages" | ||
) | ||
|
||
func AnnotationsFromFile(path string) (map[string]string, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Exported names should have a preceding doc comment that begins with the function name and briefly describes what it does, e.g.:
// AnnotationsFromFile reads and parses an annotations file that has been created by Kubernetes
// via the Kubernetes Downward API, based on Pod Annotations that are defined in a deployment
// manifest.
I surprised we're not seeing errors for missing doc comments for exported names.... maybe we need to add runs of go lint
in our tests? I think my version of Vim automatically flags this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted, and gave all exported functions proper comments.
Is there a go-to linter for Go projects? I looked at golint
, but it looks like it's been deprecated for a while.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like revive
is pretty standard, and is comparable to what golint
was.
I installed and ran revive
manually with:
go install github.com/mgechev/revive@latest
revive -formatter friendly
When I removed the doc comment that you just added and ran revive
, I see:
$ revive -formatter friendly
⚠ https://revive.run/r#exported exported function AnnotationsFromFile should have comment or be unexported
annotation_parser.go:14:1
⚠ https://revive.run/r#exported func name will be used as annotations.AnnotationsFromFile by other packages, and that stutters; consider calling this FromFile
annotation_parser.go:14:6
⚠ 2 problems (0 errors, 2 warnings)
Warnings:
2 exported
$
I'll have to see if I can add this to my Go-Vim config (and/or Goland).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ran revive
on the files I changed, and had to update some constants in config.go
that propagated to a couple other files. Had to convert from THIS_CASE
to ThisCase
.
return ParseAnnotations(annotationsFile) | ||
} | ||
|
||
// List and multi-line annotations are formatted as a single string in the annotations file, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment really helps!
pkg/secrets/config/config.go
Outdated
return fmt.Errorf(messages.CSPFK042E, key, value, "Integer") | ||
} | ||
case "bool": | ||
if value != "true" && value != "false" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can a boolean Annotation value be set to all-caps "TRUE" or "FALSE"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, not with this implementation. If we want, I can use strconv.ParseBool
to determine if a boolean setting was acceptable, which would allow "TRUE" and "FALSE", and some others:
ParseBool returns the boolean value represented by the string. It accepts 1, t, T, TRUE, true, True, 0, f, F, FALSE, false, False. Any other value returns an error.
} | ||
|
||
func TestValidateAnnotations(t *testing.T) { | ||
for _, tc := range validateAnnotationsTestCases { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is COMPLETELY a personal preference sort of thing, but in the past, I've created table-driven tests where all of these are defined in one test function:
- The test case struct (this struct can be anonymous, if it's included in an instantiation of this struct, i.e. the test list)
- The test case list (e.g.
validateAnnotationsTestCases
) - The iteration/running through all of the test cases
The benefit to this is that all definitions required for the test are gathered into one spot (one function). The downside is that the test function ends up with a LOT of lines (less visual breaks).
c6000e1
to
e2099da
Compare
a1c298c
to
1026bf3
Compare
Code Climate has analyzed commit 1026bf3 and detected 0 issues on this pull request. The test coverage on the diff in this pull request is 95.2% (50% is the threshold). This pull request will bring the total coverage in the repository to 93.0% (5.5% change). View more on Code Climate. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!!!
What does this PR do?
This PR allows for configuring Secrets Provider with Pod annotations. Annotation settings are prioritized over environment variable settings, but envvars can still be used to configure SP to maintain backwards compatibility.
Adds
annotations_parser.go
andannotation_parser_test.go
to packagesecrets/annotations
, including:AnnotationsFromFile(path string) (map[string]string, error)
ParseAnnotations(annotationsFile io.Reader) (map[string]string, error)
Adds functions to
secrets/config
package:ValidateAnnotations(annotations map[string]string) ([]error, []error)
conjur.org/
prefixGatherSecretsProviderSettings(annotations map[string]string) map[string]string
ValidateSecretsProviderSettings(envAndAnnots map[string]string) ([]error, []error)
MY_POD_NAMESPACE
is required in either caseNewConfig(settings map[string]string) *Config
New functions are used in SP main function to create a new SP Config
Acceptance Criteria Review
What ticket does this PR close?
ONYX-11827
Closes #330
Checklists
Change log
Test coverage
Documentation
README
s) were updated in this PR, and/or there is a follow-on issue to update docs, or