Add Akeyless Secrets Store Component

[kgal-akl]

Description

Added a new Secret Store component for Akeyless.

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

Issue reference

#4063

Requirements

• Code compiles correctly, component loaded successfully after compiling local daprd with added Akeyless Secret Store component, secret retrieved:

• Created/updated tests
• Extended the documentation
• Created the dapr/docs PR: Add Akeyless Doc docs#4910

[sicoyle]

if we support accessKey and aws iam, then can you pls bring in the builtinAuthProfile for aws here? Also, please be mindful of the authProfiles field in the metadata.yaml files that are meant for authentication profiles. That would be nice to leverage here if not just through the built-in aws profile :)

[sicoyle]

also the integration docs show that this component supports auth with gcp and azure, so you can also bring in and test out those builtin auth profiles if you want/have time (for gcp and azuread I think is what it's called). Otherwise, those can be a follow up effort, just please create a follow up issue for this 🙏 https://www.akeyless.io/integrations/

is a related goal of this PR to add dapr as an integration in the link i pasted for akeyless integrations? We could probably do some promoting on that front if y'all want :)

[kgal-akl]

if we support accessKey and aws iam, then can you pls bring in the builtinAuthProfile for aws here?

Can you provide a bit more info about builtinAuthProfile? I can't find this symbol in the repo or web search:

grep builtinAuthProfile -rnw ~dapr-components | wc -l
       0

the integration docs show that this component supports auth with gcp and azure

Correct, we're currently only implementing AWS IAM auth to target a specific use case. We will definitely add GCP/Azure auth when the need arises.

is a related goal of this PR to add dapr as an integration in the link i pasted for akeyless integrations? We could probably do some promoting on that front if y'all want :)

We see adding Akeyless as a Dapr Secret Store as more of a 'plugin' than an 'integration'. We have them listed in https://docs.akeyless.io/docs/plugins-overview. I'll get back to you about the promoting part.

[sicoyle]

#4036 (comment)

[kgal-akl]

if we support accessKey and aws iam, then can you pls bring in the builtinAuthProfile for aws here?

I reviewed the resources provided in #4036 (comment) on how to use the BuiltinAuthenticationProfile and AuthenticationProfile.

From what I see, when configuring the builtinAuthenticationProfiles we would be authenticating directly with the cloud provider.
In order to be able to get secrets from Akeyless we need to use the Akeyless cloud provider authentication method access ID to authenticate with the cloud provider and get an Akeyless temporary token:

We have a library https://github.com/akeylesslabs/akeyless-go-cloud-id that gets us this temporary token directly from the cloud provider metadata server running in their cluster/VMs infrastructure (e.g. AWS IMDSv2).

Given this auth flow, using the builtinAuthenticationProfiles doesn't make sense since we need to go through Akeyless or the cloud provider metadata server to authenticate and not directly to the cloud provider external APIs.

Regarding using the authenticationProfiles, it could work for us but I'm not sure how to implement it for our case.
As you can see from our metadata.yaml, the only required parameter is accessId and is used in all of the authentication methods. From what I can tell, this would mean that I would need to set accessId in each one of the profile metadata sections, e.g.:

authenticationProfiles:
  - title: "API Key Authentication"
    description: Authenticate using Akeyless API key
    metadata:
     - name: accessId
        type: string
        required: true
        sensitive: true
        description: Akeyless access ID
        example: "ABCD1233...="
      - name: accessKey
        type: string
        required: true
        sensitive: true
        description: Akeyless access key
        example: "ABCD1233...="
  - title: "JWT Authentication"
    description: Authenticate using JWT token
    metadata:
     - name: accessId
        type: string
        required: true
        sensitive: true
        description: Akeyless access ID
        example: "ABCD1233...="
      - name: jwt
        type: string
        required: true
        sensitive: true
        description: JWT token for authentication
        example: "eyJ..."

Is there a way to make a parameter such as accessId mandatory in all profile metadata? If not, I believe there's no real benefit to choosing authenticationProfiles over the current implementation.

[sicoyle]

Ah, thanks for the links and pic - that's a very helpful visual. I understand what you're saying and agree with you on this will be done outside of the scope of the existing builtin auth profile setup we have. Imo, having defined auth profiles in the metadata makes it easier for end dapr users to know concretely what auth profile they are opting into, esp since there are downstream consumers of the metadata bundle that we generate per release... so even if you do have accessId in both/all, then that is fine. I'm fine either way tbh, but again, do think it is nicer from DX to see explicit auth profiles - thoughts?

[kgal-akl]

I will refactor to use authentication profiles. I found that the only place where the authenticationProfiles key is used is in the schema here:

type ComponentMetadata struct {
	AuthenticationProfiles []AuthenticationProfile `json:"authenticationProfiles,omitempty" yaml:"authenticationProfiles,omitempty"`
}

Since I want to implement the authentication profile interface, I wanted to change the type passed into the Init function signature from secretstores.Metadata to schema.ComponentMetadata:

func (a *akeylessSecretStore) Init(ctx context.Context, meta secretstores.Metadata) error {
}

func (a *akeylessSecretStore) Init(ctx context.Context, meta schema.ComponentMetadata) error {
}

However, the schema package is inside the .build-utils directory and I can't import it into the secretstore.akeyless module.

I wanted to take get the authentication profiles from the secretstore package metadata module but it only has a Properties map:

# https://github.com/akeylesslabs/DAPR-components/blob/93d56de21248d21bb4f287920e0b97ab7c8fe165/secretstores/metadata.go#L22-L24
type Metadata struct {
	metadata.Base `json:",inline"`
}

# https://github.com/akeylesslabs/DAPR-components/blob/93d56de21248d21bb4f287920e0b97ab7c8fe165/metadata/base.go#L22-L27
type Base struct {
	// Name is the name of the component that's being used.
	Name string
	// Properties is the metadata properties.
	Properties map[string]string `json:"properties,omitempty"`
}

If I can't import and use ComponentMetadata.AuthenticationProfiles to parse the authentication profiles from the secretstore metadata, how do I parse them correctly?

[sicoyle]

Thank you for iterating with me on this! Here's another batch of feedback for ya - I still have a bit more to review on this, but this is the main I think so far :) 🙌

[sicoyle]

Suggested change

	We currently support the following [Authentication Methods](https://docs.akeyless.io/docs/access-and-authentication-methods):
	While the Akeyless Dapr Secretstore only supports AWS IAM and Kubernetes JWT authentication, Akeyless in general currently supports the following [authentication methods](https://docs.akeyless.io/docs/access-and-authentication-methods).

or something along these lines pls

[sicoyle]

Suggested change

	K8SGatewayURL string `json:"k8sGatewayUrl" mapstructure:"k8sGatewayUrl"`
	K8SAuthConfigName string `json:"k8sAuthConfigName" mapstructure:"k8sAuthConfigName"`
	K8sGatewayURL string `json:"k8sGatewayUrl" mapstructure:"k8sGatewayUrl"`
	K8sAuthConfigName string `json:"k8sAuthConfigName" mapstructure:"k8sAuthConfigName"`

[sicoyle]

i think this is missing in metadata.yaml. Pls use the allowed values field too for this one for the consts you set for the select case below

[sicoyle]

Suggested change

	accessTypeChar, err := ExtractAccessTypeChar(m.AccessID)
	accessTypeChar, err := extractAccessTypeChar(m.AccessID)

[sicoyle]

pls check if there are any other funcs that should be un-exported

[sicoyle]

do the other auth types need validations?